Subsequent debugging with error, not having the exact version of the Windows DLL on the Symbol server

Question

In my application, I use the MiniDumpWriteDump function (see dbghelp.dll) to write the dump file if it crashes when the application crashes.

I also use a symbol server to store all of my executables and pdb files, so whenever a client sends me a crash dump file, the debugger automatically selects the correct version of the executable and debug information.

I also store the Windows DLL (ntdll.dll, kernel32.dll, ...) and their debug information on the character server (using SymChk). Debug information is retrieved from the Microsoft public symbol server.

In most cases, this works fine, except when:

• client crashes in one of the windows dll files
• and the client uses a DLL that I did not put in the symbol server

This is due to the fact that it is completely unsuitable to store every taste of every Windows DLL on the Symbol server (especially with weekly patches).

So, if the client crashed, say, version 5.2.123.456 from NTDLL.DLL, and I did not put this exact version of the DLL on my Symbol server, then I was stuck. Even Microsoft's public symbol server does not help, as it provides debugging information, not the DLL itself.

My current solution is to ask the client about his DLL, but this is not always easy. Therefore, I am looking for the best solution.

Is there a way to get a debugger showing the correct call stack, or download debugging information for a specific DLL, even if you don't have the exact version of the DLL?

Alternatively, is there a way to get all versions of all (or important) Windows DLLs (from Microsoft)?

EDIT:

At the same time, I found a very simple way to solve this problem. Using the ModuleRescue utility (see http://www.debuginfo.com/tools/modulerescue.html ) you can create a dummy DLL from the minidump file. Using these dummy DLLs, the debugger is satisfied and correctly downloads debug symbols from Microsoft servers.

Answer 1

You can weaken the resolution of the WinDbg character; see my answer to a similar question. On the other hand, the solution I propose here is based on the fact that the DLLs are identical, different from the fact that different GUIDs identify their debugging symbols. Another version of the DLL will probably have different binaries, so the characters probably won't match properly, even if you can force them to load.

Answer 2

I am sure that Microsoft Symbol Server also provides binary files. I am looking in my store and I see a ton of Microsoft.dll files. I have _NT_SYMBOL_PATH defined as

SRV*F:\Symbols\Microsoft*http://msdl.microsoft.com/download/symbols 

So, he will first search my local store before trying to copy them from the Microsoft public server.

Answer 3

You may have multiple symbol servers in your symbol path. Therefore, simply configure the symbol path to point to your own server for your own private modules, as well as to the public MS server for OS modules, see "Symbol path" :

This can be easily combined with Microsoft's Public Symbol Storage using the following initial setup:

_NT_SYMBOL_PATH=srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols

The Microsoft Public Symbol Store is documented as http://msdl.microsoft.com/download/symbols .

Answer 4

? Which part is not working?

I have never been in your situation, but I expected the debugger to provide you with the correct part of the call stack that was in your code, right up to the call to the dark dll. Of course, from there to the actual crash characters it would not be available, but don't you see which NTDLL API was called and what arguments were passed to this call?

You do not say which tool you use to debug minidump: WinDBG or VS.