[SOLVED] Post-mortem crash-dump debugging without having the exact version of a Windows DLL in the Symbol Server

Post-mortem crash-dump debugging without having the exact version of a Windows DLL in the Symbol Server

Within my application, I use the MiniDumpWriteDump function (see dbghelp.dll) to write a crash dump file whenever my application crashes.

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

I also store Windows DLL's (ntdll.dll, kernel32.dll, ...) and their debug information in the symbol server (using SymChk). The debug information is fetched from Microsoft's public symbol server.

Most of the time this works perfect, except when:

a customer crashes in one of the Windows DLL's
and the customer uses DLL's that I haven't put in the symbol server

This is because it is quite undoable to store every flavor of every Windows DLL in the Symbol Server (especially with the weekly patches).

So, if a customer crashes in, let's say, version 5.2.123.456 of NTDLL.DLL, and I didn't put this exact version of the DLL in my Symbol Server, then I'm stuck. Even Microsoft's public symbol server doesn't help because it only provides the debug information, not the DLL's itself.

My current solution is to ask the customer for his DLL's, but that's not always easy. Therefore I'm looking for a better solution.

Is there a way to get the debugger showing a correct call stack, or loading the debug information of 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 the important) Windows DLL's (from Microsoft)?

EDIT:

In the mean time I found a really easy way to solve this problem. With the utility ModuleRescue (see http://www.debuginfo.com/tools/modulerescue.html) you can generate dummy DLL's from a minidump file. With these dummy DLL's, the debugger is satisfied, and correctly starts loading the debug symbols from the Microsoft servers.

Solution

It is possible to relax WinDbg's symbol resolution; see my answer to a similar question. On the other hand, the solution that I propose here relies on the fact that the DLLs are identical other than having different GUIDs identifying their debug symbols. A different version of a DLL is likely going to have a different binary, so the symbols are probably not going to match properly even if you can get them to load.