2
votes

When I load a Windows process dump file from a different machine with Visual Studio (or WinDBG), it'll display lot's of messages like:

(output from Visual Studio 2005)

'DumpDS20080626-103000-4204-4012.dmp': Loaded 'c:\symbols_cache\ntdll.dll\411096d4b7000\ntdll.dll', Symbols loaded (source information stripped).
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'c:\symbols_cache\kernel32.dll\411096d4106000\kernel32.dll', Symbols loaded (source information stripped)
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'c:\symbols_cache\wsock32.dll\41109712a000\wsock32.dll', Symbols loaded (source information stripped).
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'c:\symbols_cache\winmm.dll\411096df2e000\winmm.dll', Symbols loaded (source information stripped).
...

These messages show that the debugger is (correctly) loading the exact versions for all these system DLLs from the Symbol cache (from http://msdl.microsoft.com/download/symbols ).

However, I also see messages as these:

'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\iphlpapi.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'C:\WINDOWS\system32\mfc42loc.dll', Binary was not built with debug information.
'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\xpsp2res.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\msjet35.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\msjter35.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\msjint35.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded '*C:\WINDOWS\system32\vbscript.dll', No matching binary found.
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\mfc80u.dll', Symbols loaded.
'DumpDS20080626-103000-4204-4012.dmp': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll', Symbols loaded.
...

So there appear to be some files where the version installed on my machine actually matches the DLLs on the machine where the dump were generated and there are others, were the version on my machine doesn't match the binary that was located on the machine that generated the dump, but apparently the MS symbol server doesn't contain any bin/symbols for these DLLs.

The DLLs listed above (iphlpapi.dll, ..., msjint35.dll, ...) definitely are from MS, so I was wondering if I'm missing anything that they are not fetched from the symbol server?

Or will I just have to cope with the fact that I'll have DLLs in my process(-dumps) that have no symbols, and if a crash-call stack contains any such DLL, I'll have to be lucky for the call stack to be usable?

(Note: The output above is just an example. But you can have a crash in pretty much any DLL loaded, since your program can pass garbage to any call of any DLL.)

1
Have you tried "!sym noisy"? It will activate noisy symbol loading. And are you sure the crash has call-stacks from the above dlls? – Naveen
@Naveen - question was inspired by this question about pdm.dll. – Martin Ba

1 Answers

3
votes

Unfortunately, the process of keeping up-to-date symbols available at MS seems to be be run by a herd of donkeys, most of which died years ago and the rest of which only work a shift pattern involving alternate second-Thursdays's in May, as long as the full moon occurred on a Sunday in January.

So you can expect to (not) find lots of missing symbols, and there's nothing much can be done about it. Running Fiddler will allow you to check that the call for symbols is being correctly made and 404'd by symserv, but beyond you just have to do without.

I don't know why the whole business wasn't automated 10 years ago, so that nobody would release anything out of MS without publishing the symbols, but it hasn't been.