As I was waiting for a minidump I was grabbing on a very large and busy server application to finish writing, my mind wandered and I realized there were quite a few ways to grab a minidump today. Back in the old Windows days, when we had to program up hill in the snow both ways, there was only WinDBG. Now it seems like an application isn’t complete unless it produced a minidump. I thought I’d throw out all the ways I know off the top of my head. Of course, I’m sure there are other ways so please add them in the comments!

Note: I’m only using Windows 7 and Server 2008 R2 these days so some of these might not work on legacy Windows operating systems.

ADPlus/WinDBG’s .dump Command

The original heavy duty way to create a minidump. To create a full memory minidump, which you’ll need in order to work with .NET’s SOS/SOSEX/PSSCOR2 extensions or for native code to follow all memory like linked lists, use the /ma option.

Visual Studio

With Visual Studio 2010, the wonderful “Save Dump As…” menu option now appears on the Debug menu for both native and managed debugging. Any time you need a minidump while debugging, just grab one. Add in the fact that Visual Studio 2010 has the awesome minidump reading capabilities, especially for .NET code, we can now spend way less time in WinDBG.


Many people don’t realize that TaskManager knows all about minidumps. When you’re either in the Applications or the Processes tabs, right click on the process and select Create Dump File.

After the minidump is finished, you’ll see the dialog showing you where the dump was created. A nice hidden treat is that the path shown is a read only edit control you can select and copy so you don’t have to try to remember a long path.

You might be wondering what type of minidump TaskManager makes. How about I leave that as an exercise for the reader? OK, that’s cruel. All TaskManager created dumps are full memory minidumps.

Process Explorer

TaskManager is fine, but real developers use Process Explorer to fulfill our task management needs. Right clicking on a process lets you choose a minidump or a full memory minidump.


As I am trying to create a complete list I do need to include the Windows API that actually creates the minidumps themselves: MiniDumpWriteDump. There’s nothing stopping you from writing your own program that creates minidumps.


The sweet SysInternals ProcDump tool is designed to get you a minidump when specific nasty issues happen to your processes. It’s great for snagging dumps when you have intermittent CPU spikes or memory usage. I find that I’m using this tool constantly on production servers to get minidumps of those hard to reproduce problems. Everyone using computers needs to know about this tool, even your grandmother!


Got IIS problems? DebugDiag is for you. The ability to script when the dump occurs is pretty interesting. The always brilliant Tess Ferrandez has a great blog post that helps you to decide when you should use ADPlus/WinDBG vs. DebugDiag that’s worth reading.

Windows Error Reporting (WER)

If your company signs up for Windows Error Reporting you’ll get the same minidumps Microsoft gets. For native developers, WER is a wonderful resource but for .NET developers you only get basic minidumps so it’s not as useful.

Do you know of any other ways to capture a minidump?

  • wds_admin

    I think the real question is why would you ever want to spend less time in WinDbg? It’s way more powerful than Visual Studio.

  • wds_admin

    WER can be configured to capture dumps and save them locally whenever a process crashes.

  • wds_admin


    What is the recommended way to launch a JIT debugger for .net apps in windows 7?



  • wds_admin

    I agree with Jeff Curless! Windbg all the way!

  • wds_admin

    Also check out “Collecting User-Mode Dumps” which configures WER to locally store full dumps after a user mode app crashes.

  • jrobbins


    Great comments everyone! Thanks for contributing. Note that one drawback to the WER local dumps ( is that it only works for native applications, not .NET apps. It looks like because .NET apps have a custom error handler, they don’t let the exception percolate up to the OS level. That’s a total bummer as far as I’m concerned.

    – John Robbins

  • wds_admin

    Hi John,

    Dont leave us hanging…

    What is the recommended way to automatically capture .net crashes on Vista/Win7?


  • wds_admin

    In the old days you could use these to launch any debugger but they dont seem to work on Vista/Win7

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAeDebugDebugger


  • wds_admin

    Global flags (part of the debugging tools – gflags.exe) may be able to do it.

    Download it here:

    Don’t forget symbols:

    Then setup (click on plus before summary to open):

    Though the article describes debugging a service, should be easy to adapt it to an application using the gflags “image file” tab (point to windbg). Also, procdump may be able to help? Or auto-WER? (both are listed above)

  • wds_admin

    drwtsn32.exe prior to Win7

  • wds_admin

    Hey John
    Don’t forget SUPERASSERT

  • wds_admin

    “Do you know of any other ways to capture a minidump?”

    On those “legacy” systems… that I use every day… there are also:

    – The built-in NTSD.exe in Windows XP/2003.
    It does not have the “.dump /ma” command but there’s “.dump /mfh” to dump full memory.

    – UserDump: (but I think DebugDiag is better than UserDump).

    p.s. @Brad Wilson: alas poor drwtsn32! (But… )

  • wds_admin

    Brad wrote:”drwtsn32.exe prior to Win7″By the way… I know that drwtsn32.exe is not included in Windows Vista/2008/7 ( ) but there’s a mysterious “drwatson.exe” …. It looks like… the old drwatson from Windows 3.1 ! Seriously! Does the following box sound familiar? —————————Dr. Watson 1.00b—————————No Faults DetectedCopyright 1991-1995, Microsoft Corp.—————————OK —————————I launched a native program that crashes at will, but drwatson.exe didn’t detect any crash. So what is that for? Why is it still in Windows (XP and 2003 as well!), and why drwtsn32 is not there any longer? I’m not the only one wondering about the purpose of the ancient drwatson.exe :

  • wds_admin

    “It does not have the “.dump /ma” command but there’s “.dump /mfh” to dump full memory”No, I forgot, the one in Win2003 has also the /ma option.

  • wds_admin

    John Robbins said:
    “It looks like because .NET apps have a custom error handler, they don’t let the exception percolate up to the OS level. That’s a total bummer as far as I’m concerned”

    Not all exceptions: in .NET 4.0, the AccessViolationException actually percolates up to the OS level! The application crashes even if it attemps to catch an AccessViolationException or even an Exception. I reproduced it on Windows 7 passing an invalid IntPtr via PInvoke and BOOM! And I captured a dump with the … “resurrected” drwtsn32 :))
    I think it’s a good thing that you can’t swallow an access violation. Do you remember the infamous “catch(…)” in Visual C++ 6 ? It caused (and still causes!) a lot of pain. Yes, I still use Visual C++ 6 for some apps: the “ancient days” you mention in your book are not so ancient for me 🙁

    But in .NET 3.5 and previous, an access violation CAN indeed be swallowed with “catch(AccessViolationException ex)”

    p.s. There’s also this, but I didn’t try…

  • wds_admin

    “Add in the fact that Visual Studio 2010 has the awesome minidump reading capabilities, especially for .NET code, we can now spend way less time in WinDBG”

    I’m sorry but I can’t see those “awesome minidump reading capabilities” … well, I can see them for .NET 4.0 applications!

    But I still have .NET 2.0 and 3.5 applications around (not to mention the VC++ 6.0 applications, but it’s another story).
    I recently installed Visual Studio 2010 Premium 10.0.30319.1, and if I try to open dumps of .NET 2.0 and .NET 3.5 applications (either compiled with VS 2008 or VS 2010), I can’t see the “Debug with Mixed” button, only the “Debug with Native”, which does not find the crashing line and rants about invalid PDB files (“A matching symbol file was not found in this folder” …. even if it has just been created by Visual Studio 2010 itself!!!)
    The PDB files are good PDB files, and the dumps are good dumps, I know because WinDbg, Sos and SosEx do their work perfectly. (BTW, your “Debugging Microsoft® .NET 2.0 Applications” book is wonderful! It’s enlightening, I should have read it a long long time ago…)

    I’m not the only one:

  • wds_admin

    At last I found this post by Andrew Hall who says “only dumps of .NET 4.0 processes can be debugged using Visual Studio”:
    Not so awesome 🙁

  • Unfortunately there is a problem that many developers will hit when saving minidumps from Task Manager or from Process Explorer. If you are running 64-bit Windows (and what developer isn’t) then these will be 64-bit processes. If you are saving the dump of a 32-bit process (very likely, most applications are still 32-bit) then the dumps will be corrupt. Windbg will give cryptic warnings about overlapping modules, and VS will generally refuse to load them. This is a bug in the dump saving logic. With luck it will be fixed in Windows 8, but until then task manager and process explorer are dangerous ways of saving minidumps.

  • wds_admin

    Reading how brilliant memory dumps are, I decided to give it a go and try to create a .dmp, load it in VS2010 and see the contents of the call stack. I wrote a simple app in C++ (VS2010, Windows 7 64 bit Pro), that creates just a few entries on a call stack and then explicitly calls MiniDumpWriteDump() with option MiniDumpNormal on. 32 bit build, with and without optimisation, loaded .dmp into VS2010, clicked ‘Debug with Native Only’ and – voila – all the symbols, source files and call stack loaded correctly!
    I thought I’ll try a 64 bit version too: the same project, reconfigured to 64 bit build. Both Debug and Release builds produced dumps. With each of them, once loaded into VS, I could see all symbols loaded, but no correct call stack could be seen. However, when you put a breakpoint at MiniDumpWriteDump() and use ‘Save dump as…’ from Debug menu, all seems to be fine!… A bug in DBGHELP.DLL?

  • wds_admin

    Bruce, you just have to set correct options to debug 32-bit dumps made in 64-bit system in windbg. Like “.effmach x86” and “.load wow64exts”

  • wds_admin

    @John Robbins, you may add to the list:
    – links to the WER configuration options posted by Naveen and Aman two years ago
    – C:WindowsSysWOW64taskmgr.exe (on a x64 machine, to capture 32 bit dumps that can be opened with Visual Studio)
    – Silent Process Exit monitor:
    Unfortunately for me, it looks like it cannot monitor when a process self-terminates with TerminateProcess (only when it self-terminates with ExitProcess and when someone else terminates it with TerminateProcess). It looks like you still need to attach a debugger and set a breakpoint to trap a call to TerminateProcess. Any other ideas?
    p.s. @Sami: you can collapse “.load wow64exts” and “.effmach x86” to “!wow64exts.sw” (it should automatically load wow64exts and switch to 32 bit mode, am I right?)

  • Pingback: Debugging Emergency Plan | Programming Blog()

  • Pingback: c - Loading pdb for msctf.dll from symbol server doesn't work - CSS PHP()