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?

My problem is that our pdb files are only kept for major releases (unfortunately). This is a daily build, which I can rebuild myself, but I'm getting tripped up on errors.

With !sym noisy on: "image header does not match memory image header."

DBGENG:  C:\...\XXX.dll image header does not match memory image header.
DBGENG:  XXX.dll - Partial symbol image load missing image info
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\...\XXX.pdb - mismatched pdb

Note I've build the pdb with the dll, they are from the same RELEASE directory (should I be building debug?)

Theses are release builds (as release builds are installed on the target and crashing) should I be somehow using the debug build dlls to get more symbol information?

Answer 1

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 2

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 3

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 4

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.