WinDbg showing different call stacks when attached to process when compared to crash dump

Question

I'm analysing a deadlock that's occurring when using a native library alongside managed code. I'm using WinDbg to debug the problem with the intention of saving a dump such that the vendor might observe the issue on their premises.

When attaching to the problematic process I see the following message before any call stacks:

WARNING: Stack unwind information not available. Following frames may be wrong.

The frames actually look correct when attached directly to the process. However, when I take a dump of this file and then open the dump in WinDbg on another machine, one of the stack frames is different (the above error is displayed too.) This originally had the vendor stumped, as the code path seemed impossible.

I took the dump using:

.dump /ma filename.dmp

What would cause this discrepancy, and is there anything I can do to reliably analyse a dump file's call stacks? Might there be any other misrepresented data I should be aware of?

Answer 1

This sounds like you might have mismatched pdbs. Have you tried the !chksym and !itoldyouso commands? eg see the Bugslayer article

Another thing to try is !sym noisy that should show you which pdb files are being loaded.

See also MSDN blog

Answer 2

The warning is telling you that the debugger cannot associate one or more addresses on the stack with existing module information. As managed code is compiled on the fly by the CLR there are no corresponding modules for the code and thus the warning.

The SOS command !clrstack has the necessary info from the CLR to display a meaningful stack (or at least without the warning). If you use any of the native stack dump command, you'll see this warning for managed code.

The upcoming book Advanced .NET Debugging has additional details. See http://advanceddotnetdebugging.com/