How do you identify (and get access to) modules/debug symbols to use when provided a windows .dmp or .minidmp

Question

In a way following on from reading a windows *.dmp file

Having received a dump file from random customer, running the debug session to see the crash, you often find it is in a MS or other third party library. The next issue is that you may not have knowledge of the PC setup to such an extent that you can ensure you have the actually modules available.

For instance I'm currently stuck trying to get symbols to load for ntdll.dll (5.01.2600.5512). In MSVC 2005 the path column in the modules list window shows a * before the fully pathed file name, and refuses to load symbols I have downloaded for XP/SP1/SP1a/SP2/SP3.

I have the symbol server setup to download from the internet and store in a local cache which seems to have been working fine for modules that I do have on my PC. Using GUI equivelant to the method

Set _NT_SYMBOL_PATH=srv*d:\SymbolCache*\\server1\Third-Party-PDB;srv*d:\SymbolCache*\\server2\Windows\Symbols*http://msdl.microsoft.com/download/symbols

Perhaps I have the wrong symbols, but as new ones are not downloading where do I go to next? Do I have to contact the customer and ask what SP they have installed, and any other patches? Do I have to install that machine and then run up the debugger with the dmp file to get the symbols I need?

Answer 1

Try following the instructions at this kb article, and make sure your symbol path is configured correctly, that WinDbg has access to it, and that the ntdll symbols (for example) are actually downloaded to your symbol cache. The article also provides instructions on how to manually download and verify symbols in you cache via the SymChk tool.

Answer 2

What are you using to debug the minidump? I.e., WinDBG or Visual Studio? And how was the minidump generated?

There should be enough information in the minidump to resolve system dll symbols correctly. Are you using a local download of symbols or http://msdl.microsoft.com/?

Update: You should be able to add the public microsoft symbol store to Tools->Options->Debugging->Symbols->Symbol file (.pdb) locations, and then manually load the symbols by right clicking on the module in the Modules window and loading them if it isn't done automatically.

It's also possibly (likely) that VS 2005 doesn't look at _NT_SYMBOL_PATH to resolve minidump symbols.

MSN

Answer 3

If you are using WinDbg (part of the Debugging Tools for Windows package), then it's simple to have it pull the right symbols for you from Microsoft automatically. Configure the symbol path using the ".symfix" (or ".symfix+", to simply append to your existing symbol search path) command.

Once you have that done and you have the crash dump loaded in WinDbg, type ".reload /f" to cause WinDbg to reload the symbols. It will use the information within the dump file itself to pull the correct symbols from Microsoft's public symbol server, regardless of what DLLs you have on your machine.

If for some reason the symbols aren't loading properly after you have done this, enter "!sym noisy" into WinDbg's command window and reload the symbols again. As WinDbg attempts to load them, you will see it output any errors that it encounters in its search/load process. These error messages will help you further diagnose what is going wrong and why the correct symbols aren't being loaded.

This post has information that may also be of use.

Answer 4

If you're typing "Set _NT_SYMBOL_PATH = srv..." into a command prompt, there are two things to consider:

• cmd.exe's set command does not ignore whitespace, so this defines a variable called "_NT_SYMBOL_PATH ", not "_NT_SYMBOL_PATH".
• You must start the debugger as a child of that command prompt. However, you don't have to do this if you use the Control Panel to set persistent environment variables, or if you use the setx command (in Windows Vista or one of the Windows Resource Kits).

If you're setting the symbol path some other way, then this doesn't apply.