I've used minidumps on many game projects over the years and they seem to have about a 50% chance of having a valid call stack. What can I do to make them have better call stacks?
I've tried putting the latest dbghelp.dll in the exe directory. That seems to help some.
Is Visual Studio 2008 or 2010 any better? (I'm still on VS 2005).
The code I use looks like this sample.
What's missing from your callstack? Do you have a bunch of addresses that don't resolve to valid function names (ie, 0x8732ae00 instead of CFoo:Bar())? If so, then what you need is to put your .PDBs where your debugger can find them, or set up a symbol server and set the "Symbol Paths" in the right-click context menu of the Modules pane.
We store every .PDB from every binary every time someone checks in a new Perforce changelist, so that when a dump comes back from anyone inside the office or any customer at retail, we have the .PDB corresponding to the version of the game they were running. With the symbol server and paths set, all I have to do is just double-click the .mdmp and it works every time.
Or do you have a call stack that appears to only have one function in it? Like, 0x8538cf00 without anything else above it in the stack? If so, then your crash is actually the stack itself being corrupted. If the return addresses in the backchain have been overwritten, naturally the debugger will be unable to resolve them.
Sometimes also you'll find that the thread that actually emits the minidump is not the one that threw the exception that caused the crash. Look in the Threads window to see if one of the other threads has the offending code in it.
If you are debugging a "Release" build -- that is to say, one compiled with all optimization flags turned on -- you will have to live with the fact that the debugger will have trouble finding local variables and some other data. This is because turning on optimizations means allowing the compiler to keep data on registers, collapse calculations, and generally do a variety of things that prevents data from ever actually being written to the stack. If this is your problem then you'll need to open up the disassembly window and chase the data by hand, or rebuild a debug binary and reproduce the problem where you can look at it.
I dont use minidumps, but rather dump teh stack by "hand" into a logfile (see www.ddj.com/cpp/185300443 and http://stackoverflow.com/questions/590160/how-to-log-stack-frames-with-windows-x64).
I encounter a similar behavior like you do: Sometimes there is a valid call stack, sometimes there is not. In a minor number of cases the stack might be really corrupted. In maybe 1/3 of all cases the installed Exception handler is not called at all! I guess that its somehow a problem of the windows structured exception handling.
Turn off Frame Pointer Optimization, if you need stack dumps. Frame pointers are used to explicitly define stack frames. Without them, the debugger has to deduce the location of each frame.