In our last post, we discussed what symbols were and why they were important in debugging. Today, we’re going to take a look at how to set up your symbols for debugging. Setting up the symbols can be a daunting exercise. This is especially true if you consider the fact that one module has several different symbol packages – one for each release version of the module. The debugger has to be able to locate each of the symbol files that corresponds to the correct released version. There are two pieces of information used by the debugger to return the correct information – the location of the symbols path and the headers within the module itself that it uses to validate the symbol files.
A symbol path is nothing more than a set of locations that tell the debugger where to look for symbols. There are a couple of ways you can locate the symbol path in the debugger. The first is to use File –> Symbol File Path … from the main menu in the debugger. This brings up the following window:
As you can see, there are two file paths listed – one on my C: drive and one on my Z: drive – in both cases, in a folder called Symbols. The second method is to use the .sympath command as shown below:
2: kd> .sympath
Symbol search path is: c:\symbols;z:\symbols
As you can see, the same information is returned. In this scenario, I would need to ensure that the proper symbols are placed in the folder prior to debugging the application or crash dump – if I do not, then the debugger will not find the correct symbols.
This is where a symbol server comes in handy. A symbol server allows the debugger to automatically retrieve the correct symbol files. In several of our previous posts we have referred to the Microsoft symbol server – which we are going to go ahead and configure now. The symbol server is activated by using a specific text string in the symbol path. When the debugger needs to load symbols, it calls the symbol server to locate the correct files. The symbol server maintains a symbol store. Let’s go ahead and configure our debugger using the Microsoft symbol server. The basic syntax in the symbol path is as follows: SRV*[path to cache folder]*[path to symbol server]. The SRV piece of the string indicates that we are using a symbol server. The [path to cache folder] is a folder that is used to cache symbols locally. This becomes especially useful for common binaries such as KERNEL32.DLL or SHELL32.DLL. The [path to symbol server] is fairly self-explanatory. You can combine this path with other symbol paths, using a semi-colon as the delimiter. By doing this you can create a symbol search path that includes multiple folders and symbol servers that contain all the symbols needed for a debug session. So let’s go ahead and reconfigure our debugger to use a symbol server – specifically the Microsoft public symbol server. We’re going to use the .sympath command in the debugger to configure this. The command syntax is .sympath SRV*[path to cache folder]*[path to symbol server]. The command and the output are below:
2: kd> .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
If you are an application developer or have access to private symbols, the way you would want to set this up would be to have your private symbol server as the first entry, and the Microsoft public symbol server as the last entry.
Finally, you can also set the Symbol Path as an environment variable on the system. We discussed how to do this in our recent post, Two Minute Drill: UMDH.EXE.
And with that, another post comes to a close. More information on Symbol Servers and Symbol Stores is below. Until next time …
- Microsoft KB 311503: Use the Microsoft Symbol Server to obtain debug symbol files
- Debugging Tools and Symbols: Getting Started
- MSDN: Symbol Servers and Symbol Stores
|Share this post :|