The symbol path specifies locations where the Windows debuggers (WinDbg, KD, CDB, NTST) look for symbol files. Microsoft OS symbols are located at: https://msdl.microsoft.com/download/symbols
You can set the symbols in multiple ways:
- If you are an active debugger, setting it up in the environment path is the best option. You can directly set the _NT_SYMBOL_PATH in the environment variable path Ex: _NT_SYMBOL_PATH=srv*C:\Symbols\MsSymbols*http://msdl.microsoft.com/download/symbols
- GUI via the WinDbg interface: In WinDbg’s GUI you can access symbol settings from:–(Menu) File->Symbol File Path … (Ctrl+S)
- Using Command line on WinDbg prompt
Useful Commands:
–.sympath-> get/set path for symbol search
–.sympath ->+XY append XY directory to the searched symbol path
–!sym noisy ->instructs the debugger to display information about its search for symbols
–ld kernel32 ->load symbols for kernel32.dll
–ld * ->load symbols for all modules
–.reload ->reloads symbol information
–x kernel32!*->examine and list all symbols in kernel32
–x kernel32!*LoadLibrary* ->list all symbols in kernel32 which contain *LoadLibrary*
–dt ntdll!*->display all variables in ntdll
Combining cache* and srv*
If you include the string cache*; in your symbol path, symbols loaded from any element that appears to the right of this string are stored in the default symbol cache directory on the local computer. For example, the following command tells the debugger to use a symbol server to get symbols from the store at https://msdl.microsoft.com/download/symbols and cache them in the default symbol cache directory.
.sympath cache*;srv*https://msdl.microsoft.com/download/symbols
If you include the string cache*localsymbolcache; in your symbol path, symbols loaded from any element that appears to the right of this string are stored in the localsymbolcache directory.
For example, the following command tells the debugger to use a symbol server to get symbols from the store at https://msdl.microsoft.com/download/symbols and cache the symbols in the c:\MySymbols directory. .sympath cache*c:\MySymbols;srv*https://msdl.microsoft.com/download/symbols
The first rule for anyone thinking of using the Windows debugger is to get the current version. The debugger is updated on a routine basis and as a result it really is important to ensure that you grab the latest and greatest version. As of the writing of this article, the current version can be found at:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx.
There is usually a release version as well as a pre-release version available. Grab either one – they are very likely to be better than the debugger version you are using.
If you plan on building your own debugger extensions (probably not likely when you first get started, but once you use this debugger you’ll be chomping at the bit to add your own extensions to it) make sure you choose a “custom” installation and install the debugger SDK – otherwise you won’t have the header files and libraries you need.
OK. Having downloaded the debugger the first challenge is normally getting the symbols set up. Fortunately, the debugger team at Microsoft has made this incredibly easy. If you go back to the same place you got the debugger (http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx) you will see information about using the symbol server as well as downloading the symbols for various versions of Windows. We strongly recommend that you use the symbol server whenever possible, especially when getting started with the debugger. To set up symbols using the symbol server you will need to set up a temporary storage area – any directory within your file system will do the trick If your disk space is at a premium and you are using NTFS, make sure you turn on compression for that temporary storage area. For example, on my system I place the symbols in f:\symbols\websymbols but you can put them anywhere – even on a network drive. Then, once I start up the debugger and before I start debugging anything I set up the initial symbol path. Do this by pressing Ctrl+S or by choosing “Symbol File Path” from the File menu. This will pop up a little dialog box where you enter your symbol file search path. So in my case I entered:
srv*f:\symbols\websymbols*http://msdl.microsoft.com/download/symbols.
Having done this, you can now attempt to connect to your remote system (if you are doing live debugging) or your crash dump (if you are doing post-mortem debugging). In either case the debugger will ask you if you want to save the workspace. You want to say YES here because that will record that symbol path as your base symbol path. Now, when you create a new workspace it will always start with this path (note that if you have existing workspaces, this will not update them).
Alternatively, if you forgot to setup your symbol search path to start with and the debugger scolds you — or if you can’t remember the syntax of the symbol server’s search path — you can always break-in and tell the debugger to setup your symbol path for you:
.symfix f:\symbols\websymbols
Where f:\symbols\websymbols is, once again, the location of my local symbol store.
You can go back and add additional paths at any time – these will be specific to the thing you are currently debugging, so they won’t show up in your base workspace. Each additional path should be separated using a semi-colon (;). So if my driver symbols are in z:\mydriver, I would then have the following in my symbol search path:
srv*f:\symbols\websymbols*http://msdl.microsoft.com/download/symbols;z:\mydriver
Suppose, however, that the debugger is telling you that it cannot find your symbols or the symbols for OS modules (oh, like ntoskrnl.exe since the debugger is pretty much useless if it cannot find those symbols). In that case you can enable noisy symbols, so the debugger will report to you where it is looking for symbols. In our experience, once you can see where the debugger is looking, you will know where it is not looking and hence why it cannot find your symbols. Maybe you’ve entered the path incorrectly (WinDBG does not have a built-in spell checker, nor does it have any fuzzy logic module that says “oh, gee, they must have meant this OTHER directory with a very similar name). Maybe the symbols really do not match (hey, it happens) but at least you’ll know where the debugger is checking!
At this point you should have everything set up and working. Happy Debugging!
