Until now, it is has been assumed that debug symbol files have aligned perfectly. Admittedly, that is a major assumption. However, the advent of symbol stores and servers makes me optimistic that your symbols are aligning without the obligatory drama. Having the correct debug symbols files for the environment and application make the debugging experience infinitely easier. With symbol files, function names, parameter names, local variables, source code line, and data to resolve, frame pointer omissions (FPOs) are available. Without symbol files, little of this valuable information is available, which makes your debugging quest much more difficult.
Debug symbol files are versioned. Different versions of debug symbol files are available for separate Windows environments. Windows 98, Windows 2000, Windows XP, and other Windows operating environments do not have identical symbols. Service packs may also have different symbols. Because of the large assortment of symbol combinations, obtaining the correct symbols for an environment becomes a trial-and-error process—which is further complicated when performing postmortem analysis. The dump may have originated on another machine that has a different operating system, which requires having the symbols for the environment on the source machine available on your machine. Things are getting complicated very quickly. A more direct approach is needed, and the solutions are symbol servers and symbol stores.
Symbol servers orchestrate the downloading of required symbols from a symbol store. The symbol server assumes the responsibility of finding the correct symbols; a symbol store is a repository of related debug symbol files. Symbol servers consult with the symbol store to download the correct versions of the debug symbol files. Microsoft publishes a public symbol store for developers, which can be accessed here:
You can download symbols directly instead of using symbol servers. However, the approaches are not mutually exclusive. Symbol packages for different Windows environments are downloadable from this location:
Symsrv.dll is the symbol server distributed with Debugging Tools for Windows, and it must be installed in the same directory as the debugger. Symsrv contacts the listed symbol stores and downloads debug symbol files into a downstream directory. Files can be transferred over http and https.
This is the generic syntax to download debug symbol files with a symbol server:
The following command leverages the symsrv.dll symbol server. The symbol server is instructed to contact the Microsoft Public Symbol Store to download missing or correct versions of symbol files. The symbols are transferred to c:\ symbols, which is the downstream store:
Because symsrv.dll is the most prevalent symbol server, an abbreviated syntax is available that is specific for that server:
The following command uses the abbreviated syntax and is identical to the previous expanded command that used the symsrv.dll symbol server:
As shown in the following syntax, symbol servers can have multiple downstream servers. If the symbol file is not in DownstreamStore1, it is downloaded from DownstreamStore2. Furthermore, if the file is not in DownstreamStore2, DownstreamStore3 is contacted. If the file is found there, it is downloaded from DownstreamStore3 into DownstreamStore2 and then DownstreamStore2 into DownstreamStore1. This pattern continues until the debug symbol is found or the symbol stores are exhausted.
WinDbg and Visual Studio .NET read the _NT_SYMBOL_PATH environment variable for the default path for the symbol server. Use the System tool in Control Panel to create or modify the _NT_SYMBOL_PATH environment variable.
The Microsoft Public Symbol Store downloads the symbols for the environment. You also need the symbols for your application. Symbol files are not always distributed with release versions of a product, so a production server might not have the required symbol files. It is imperative that the debug symbol files for the release product be maintained somewhere, such as a private symbol store, for debugging if needed.
Visual Studio .NET creates a symbol file (PDB) for both debug and release versions of the product. It is important to retain the symbol files for each version of the debug and release product. Because clients may have older versions of your product, the debug symbol files for those versions must also be retained and available.
In WinDbg, the symbol path can be set via the user interface or the command line. From the user interface, select the Symbol File Path menu item from the File menu. From the command line, the .sympath directive can display or set the symbol path. When the symbol path is changed, the .reload directive resynchronizes and potentially downloads additional symbol files.
The !sym noisy command helps diagnose errors in loading debug symbol files. This command displays detailed information on each symbol that should be downloaded, which is helpful for resolving symbol problems. The !sym quiet command, which is the default, suppresses the extra binding data.