Take the 2-minute tour ×

I'm calling MiniDumpWriteDump from .NET to generate a minidump, and that works fine. However, when I load the resulting dump into VS 2010, I don't see any useful info. In particular, the Call Stack window looks something like this:

Call stack

It doesn't contain any managed frames, although I'm writing the dump while in an exception handler in managed code. Also, it doesn't contain any frames located in my exe.

Any idea why this happens?

BTW when I create a dump manually from the VS debugger, the dump does contain managed frames as expected.


I've found a Microsoft Connect issue about this. It says:

Currently the CLR does not support managed processes taking their own dumps.

Anyone know if that's still true?

share|improve this question
Debugging minidumps with managed code remains a questionable joy in VS2010. Just some hints: you need to enable the Microsoft Symbol servers so that the debugger can properly walk the unmanaged stack with the aid of the Windows .pdb files. And you need to turn the MiniDumpWriteDump() options to eleven so the garbage collected heap gets captured in the minidump. You're doing it right if the one you create is as huge as the one that VS creates. –  Hans Passant Aug 17 '11 at 16:16
@stefan msdn.microsoft.com/en-us/magazine/cc188701.aspx - "After pounding through everything I could think of, I realized that the only way I was going to get the information from other stacks was to spawn off a process that would pass that information back into SUPERASSERT.NET." and "While the idea would be to walk all the stacks from inside the process, there's no viable way to make that happen." –  Jeremy Thompson Sep 16 '11 at 4:57
add comment

3 Answers

up vote 2 down vote accepted

I've found my mistake. I was looking at the call stack of the wrong thread (I didn't realize there was more than one thread running). Now I can see the managed call stack just fine.

share|improve this answer
add comment

I do something similar in my application (i.e. calling MiniDumpWriteDump and then investigate the dumps in the debugger).

Whenever I have this problem, there are two possible causes:

  • either the symbol information is missing
  • or the DLL or EXE that was used by the process at the time of the dump is missing

The first cause is easy to solve. In VS2010 you can simply right click the DLL in the call stack or in the Modules window and choose 'Load Symbols from Microsoft Servers'.

The second cause is more difficult to solve. If the DLL or EXE is missing, the debugger refuses to let you debug it, and even refuses to look at the symbols. The trick is to generate a dummy DLL/EXE from the DMP file. Look at http://www.debuginfo.com/tools/modulerescue.html for the utility MODULERESCUE. This utility can generate dummy DLL's and EXE's for a given DMP file, just enough to satisfy the debugger so that it wants to load the symbols again.

share|improve this answer
Thanks. I've found my mistake, it was that I was looking at the wrong thread. –  Stefan Monov Sep 9 '11 at 14:30
add comment

Keep in mind that you should call MiniDumpWriteDump from an exception filter which is supported by VB.NET but not by C#.

Have a look at these links:

Getting good dumps when an exception is thrown

Writing Minidumps from Exceptions in C#

share|improve this answer
Thanks. I've posted a follow up question here: stackoverflow.com/questions/7372535/… –  Stefan Monov Sep 10 '11 at 15:06
add comment

Your Answer


