WinDbg Dr. Watson minidump - requires pdb/dll originally built for installed version?

Question

I have a mindmp file from a target\'s application crash. Is it possible for me to rebuild the dll/pdb files for a version of software and have windbg load symbols correctly?

Answer 1

The ChkMatch utility is designed for this exact scenario. As long as you have the original .EXE, you can recompile the sources (with the same compiler and compiler settings) and patch the new .PDB to match the old .EXE.

In this example, OriginalExecutable.exe is the executable that no longer has a .PDB file, and RebuiltPDB.pdb is one that has been produced by rebuilding the original source.

chkmatch -m OriginalExecutable.exe RebuiltPDB.pdb

Now, as long as the two files have their original names, The debugger should accept them as a matching pair.

Answer 2

This is too late to help Doug, but for the sake of anyone who comes across this question, another thread (Is it possible to load mismatched symbols in Visual Studio?) pointed out a way to get WinDbg to accept mismatched .PDB files

.symopt_0x40

Answer 3

In my experience probably not.

If you have the exact build directory and build with the exact same compiler settings then this might work. You definitely will not be able to load symbols from a debug build against a release crash dump.

You will need to turn on the 'load anything' options: .symopt+0x40 to get windbg to ignore the timestamp differences.

Answer 4

PDB files are tied to their EXE files by a GUID and an "age" (it's a sequence number). These are embedded in the EXE, and into the PDB. The GUID is regenerated on each complete build, and the "age" is changed on each incremental build.

The debugger uses these to ensure that it's looking at the correct PDB for the EXE file.

I didn't know about the "chkmatch" tool mentioned by SteveMan, but I suspect that it works by patching up the GUID/age so that they match.

Answer 5

if you still have the exact source code the image was compiled from, then rebuild it producing a new pdb file and then instruct WinDbg to forcibly load this pdb when you open the crash dump - it worked once in my practice.