Crash dump - WinDbg - force PDB files to match doesn't work?

Question

I have a crash dump for a customer's application built with a very old version of our dll (release build, don't have original symbols) that I've been analyzing in WinDbg.

In order to get more information, I rebuilt the dll in release mode, with symbols this time, using the same compiler version and I believe the same settings as when the dll was originally built. I added the symbol file to my symbol path, but the WinDbg extension !itoldyouso tells me the module in the dump doesn't match the PDB file. Enabling SYMOPT_LOAD_ANYTHING doesn't help either.

!itoldyouso tells me they don't match because the module has no pdb sig (value 0), versus the recreated symbol file I made (with a valid pdb sig). How do I get them to match?

Solution 1

Have you tried .reload /i foo.dll ?

For verbose output try:

!sym noisy;.reload /i foo.dll;x foo!*test*

Solution 2

Try chkmatch (http://debuginfo.com/tools/chkmatch.html) - it's able to override signatures in pdb file so exe and pdb will match. Also, some time ago I wrote a post about checking pdb files "offline", maybe you will find there something useful: http://lowleveldesign.wordpress.com/2011/12/09/pdb-file-out-of-debugger/.

Solution 3

Its unfortunate that you do not have the matching symbols for your DLL :(. As per my understanding, any attempt now will not be able to get you an exact matching PDB.

Recycling some old threads which should help :

Is it possible to (re)create a PDB file after a DLL is made

Tool to find if dll (or) exe and PDB file match

Your best bet would be

a. sync your code back to the time when the DLL was released

b. build and create PDB using the same tool set.

c. use .reload /i option to load symbols

Comments

[JosephA]

Yes, it loads the symbols of foo, but in the verbose output I see the mismatch reported as well: "DBGENG: foo.dll has mismatched symbols - type ".hh dbgerr003" for details"

[Marc Sherman]

Of course they will be reported as mismatched because they were not built when the DLL was built. But as long as you use the same compiler and setting (which you mentioned) AND the source code has not changed at all, then the symbols should work.

[JosephA]

I suppose I was operating on the assumption unless I have a match I simply can't trust the call stack, though maybe as you said they will never match, but perhaps despite that I can still have a mostly valid call stack.

[Gabe]

Why does this work? That is, what does /i signify?

[Marc Sherman]

From Windbg's Help: "Ignores a mismatch in the .pdb file versions."

[Adrian McCarthy]

It's a great suggestion, but chkmatch -m will likely fail if the age fields are different, which seems likely here. The binary probably has 0 for the PDB signature and the age. chkmatch won't change the GUID if the ages don't match, and the age in the PDB is almost certainly not 0.