Getting full user mode dumps automatically when your process crashes

I recently got a question about if it is possible to generate full user mode dumps automatically every time the process crashes (without having debug diag or adplus installed and monitoring your system).   This would be useful for example if you are setting up a site, and you want to make sure you get dumps if it ever crashes so that you don’t have to repro the issue at that point, just to get data.

It turns out that starting with Windows Server 2008 and Vista + SP1, Windows Error Reporting (WER) will let you do just that.  It even worked on my Win 7 machine.

The documentation here says that “Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature”. 

It’s a bit hard to tell what this actually means but I think this is added here due to ambiguity about what constitutes a crash.  For example if you have an exception in an ASP.NET application that is handled by the ASP.NET error handler (i.e. showing you the yellow ASP.NET error page) that is not a “crash” since ASP.NET handles the error, and the process just continues.  However for example a StackOverflow, or any unhandled .net exceptions on finalizers or non-request threads, that cause the process to “terminate unexpectedly” will be caught by WER and produce a dump if you configure it to do so.

Setting this up

I set this up on my machine (per the article) by adding a registry key specific to w3wp.exe to monitor crashes for my ASP.NET applications

HKLMSoftwareMicrosoftWindowsWindows Error ReportingLocalDumpsw3wp.exe

Under this key I added 3 values (types and descriptions can be found in the MSDN article)

  Value Comment
DumpFolder c:mycrashdumps This is the location where the dumps will be generated, so the user that the W3WP.exe process is running under needs access to write to this location.
DumpCount 10 Maximum # of dumps in the folder, depending on the size of the process 10 dumps can take up a lot of disk space, so monitor carefully.
DumpType 2 To debug .net crashes a full user mode dump is often necessary.

I also had to disable the JIT debugger for this to work, under

         HKLMSoftwareWow6432NodeMicrosoftWindows NTCurrentVersionAeDebug

By renaming the Debugger value to Debugger-unused, and now it is producing crash dumps for stackoverflows and other unhandled exceptions.

A word of caution

As always, any modifications to the registry should only be done by trained professionals:) and only after carefully backing up the registry first etc. etc.  I take no responsibility for any issues caused by such modifications.

Also, keep in mind that as mentioned before, the dumps can get pretty big if you have processes that produce a lot of memory so be wary about the amount of disk space that this can consume.

Have a good one,

Comments (10)

  1. Jason Hall says:

    Very useful information for working through those tough to repro. issues.

    Thanks Tess!

  2. Gregory Suvalian says:

    I think you have the same capabilities without any registry modifications if you login to console after crash and see that "process crashed, do you want to upload details to Microsoft", don't click any buttons, go to technical details and it'll provide location of the dump files. Copy them out of that location and then you can cancel that dialog (if you cancel dialog before that then those files will be wiped out).

  3. Tess says:

    Good point Gregory,  

    The only issue with those is that they are not full usermode dumps with /ma, so some data might not be available.  Having said that though, with 4.0 apps it looks like you can get a lot of the data you need from those.


  4. kevin025 says:

    Weird stuff.

    Have you tried? In my test environment on Windows Server 2008 x86 with registry settings in place, any dumps are not created in ASP.NET 2.0 Application with StackOverflowException or whatever. On the other hand, exception in win32 application could create dump on the path by DumpFolder settings.

    The difference between Win32 and ASP.NET 2.0 is DW20.exe, which is not created by the exception in Win32 App, but ASP.NET.

  5. PaDaArvind says:

    Configure User Mode Process Dumper 8.1 for pre-Vista/2008.

  6. Swootech says:

    kevin025, the WER settings only work for native and .NET 4.0 – Not for earlier .NET versions.

  7. Wade Mascia says:

    For downlevel OSes where this isn't an option, or if you have trouble w/ the WER feature for whatever reason, you can register DebugDiag as the JIT debugger by running "DbgHost.exe -JITInstall".  This would require that DebugDiag be *installed* on the machine, but the process would not have to *run under* the debugger.  DbgHost would only be invoked when the application crashes, and it will save a dump file of the process.


  8. Kiran says:

    I would like to use it as we would like to monitor our application for crash (Which happens abruptly). But we have a scheduled restart of our server at every midnight and wit this combination "adplus -crash …" will not work.

    So, I found this as a solution. But somehow it is not working for me, followed all the steps. But still no luck.

    I'm using Windows Server 2008 R2 64 bit. And our application works on .NET 3.5. Just read from this link :…/bb787181%28VS.85%29.aspx that "For the managed .net applications. this feature only works in .NET Framework 4.0 on Windows 7,  won't work in .NET 3.5 and below." — Is it the case? If yes then what's the alternative? FYI – I Click on Start-> Run and type WERCON)



  9. Alfred (Poon) says:

    This does not seem to work on Windows 8.1 Enterprise, but some posts I came across suggests it should.

    I have a test application that dereferences a null pointer and crashes, but Windows 8 immediately pops up a crash dialog, and no local crash dump is saved. I can use Local Group Policy Editor to enable WER Report archive but all that is stored is the .WER file.

  10. Iuliana Ciura says:

    For Windows 8.1, HKLMSoftwareMicrosoftWindowsWindows Error ReportingDebugApplicationsw3wp.exe has to be put on 0. For the JIT debugger to stop popping up and the dump to be created.