views:

224

answers:

4

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)?

+1  A: 

I'm pretty sure Microsoft's symbol server also provides the binaries. I'm looking in my store and I see a ton of Microsoft .dll files. I have my _NT_SYMBOL_PATH defined as

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

This way it will search my local store first before trying to copy them down from Microsoft's public server.

Luke
The Microsoft symbol server only contains the symbols, not the binaries (I'm quite sure of that). I have also _NT_SYMBOL_PATH set to a similar value, but if the DLL (used by the customer, and referenced in the crash dump file) is not on my system or in my symbol server (or symbol server cache), the debug information can't be loaded either. So the symbols only help if also the DLL is present in your symbol server.
Patrick
Microsoft Symbol server usually _does_ contain the binaries. It might not have them for this particular case, though.
Roger Lipscombe
Which tool do you use to debug crash dumps? WinDBG works fine without dll's if only pdb is present. And I've seen cases when Visual Studio was unable to load symbols without dll's.
Oleg
A: 

? What part isn't working?

I've never been in your situation, exactly, but I would expect the debugger to give you the correct portion of the call stack that was in your code, up to the call into the dark dll. Of course, from there down to the actual crash symbols would be unavailable, but can't you see which NTDLL API was being called and which arguments were passed to that call?

You don't say which tool you're using for minidump debugging: WinDBG or VS.

Die in Sente
Every time we make a production executable, we store it (and its debug info) into our symbol server, so if we get a crash dump file from a customer we can see our own functions in the call stack. The problem is that if the app crashes in a Windows DLL (e.g. because we pass wrong arguments), and the DLL is not installed on my PC (because the customer has a different OS version or different patch) that I can't see the call stack or the debugger reports that the call stack is unreliable (and often it is). This is because I cannot download the customer's DLL from the MS site only the debug info.
Patrick
I mainly use VS, but if I find a solution for WinDbg I am willing to use that in those cases.
Patrick
+1  A: 

You can have multiple symbol servers in your symbol path. So simply set up the symbol path to point to your own server for your own private modules, and to the public MS server for OS modules, see Symbol Path:

This can be easily combined with the Microsoft public symbol store by using the following initial setting:

_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.

Remus Rusanu
+1  A: 

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.

Aaron Klotz
Give me some time to look at this solution. It looks like this may solve quite some problems. If I confirmed this to work in my situation, I'll mark this as a solution.
Patrick