views:

61

answers:

2

I've read a lot of similar questions, but I can't seem to find an answer to exactly what my problem is.

I've got a set of minidumps from a 32-bit application that was running on 64-bit Windows 2008. The 32-bit Visual Studio on my 32-Bit Vista Business wouldn't touch them at all, so I've been trying to open them in WinDbg.

I don't have the EXACT corresponding .pdb files (we only started saving them AFTER this particular release), but I have .pdbs built by the same machine with the same code. I also have access to the exact executable that created the minidumps.

I found a nifty little application called ChkMatch that can make .pdbs match an executable... the only difference (according to ChkMatch) was age, so I matched my newer .pdbs to the original executable.

However, when I load it in WinDbg, it still says that it is a "mismatched pdb" then, since I had set .symopts+0x40 it tries to load them anyway. I then get the warning:

*** WARNING: Unable to verify checksum for myexe.exe

I ran !lmi myexe and saw that, indeed, the checksum of the executable was in fact zero. From poking around a bit, I've found that the executable should have been built with the /release flag to have a checksum. That's all well and good, but I can't exactly go back in time and rebuild (if I did though, I'd definitely save the original .pdbs :-P ).

Is there anything I can do here? Seems a little ridiculous I can't make things match here at least enough to get a call stack.

A: 

you don't need the checksum to get a call stack - this warning can be safely ignored.

to get the stack you need to issue the stack command (any variant of k).

if the minidumps are any good (i.e. describe an actual fault), you should first try the auto analysis !analyze -v which will get you started.

come back when you have exhausted your expertise :o)

Right, I definitely knew that already. The call stack was pretty barebones, so I was pretty convinced that it was due to my lack of symbols. I put a new executable in place (with exact matching symbols), reproduced the issue, and got the same call stack. Looks like I'm back to square one.Accepting your answer as it's the only one here.
Morinar
A: 

If you're working with minidumps then you have to set your image path (Ctrl+I) to point to a location with the images in the dump. The trouble with minidumps is that they don't contain any code or data from the executables on the target, so you have to supply them yourself.

-scott

snoone

related questions