Windows Error Reporting dumps VS procdump.exe

dumpwindows-server-2012-r2

Can somebody clarify if memory dumps produced by WER are the same as those produced by procdump.exe? Can two these tools conflict when used simultaneously? What would be the right approach if my goal is to troubleshoot "service terminated unexpectedly" type of event for a service (on a Server 2012 R2 platform)?

Best Answer

Both procdump and WER are good for capturing user-mode crash dumps when an application crashes.

The rule of thumb is that the more comprehensive the dump, the more useful it can be, because mini-dumps and hybrid-dumps and custom-dumps all omit bits of data that might have been useful in a root cause investigation for the sake of saving disk space.

WER captures mini-dumps by default, but it can be configured to capture full dumps.

(When I say "full dump" in this context, I mean the full user-mode process address space of the process in question -- anything kernel-mode is out of scope.)

procdump.exe, on the other hand, is a Sysinternals tool (Mark Russinovich, Andrew Richards, et al,) that is designed to be a lot more flexible than WER. If WER was a butter knife, then procdump is a Swiss army knife. For example, procdump.exe can be configured to automatically capture a dump (or series of dumps) when a process stays > 90% CPU usage for 10 seconds, or > 500MB of memory usage, etc. etc. procdump can also be set up as your permanent AeDebug postmortem debugger, which basically makes it a replacement for WER at that point.

WER works well enough, (especially when configured to capture full process dumps,) and both WER and procdump capture the same kind of dump, but you only need one or the other. There's not really any sense in trying to use them both.

procdump -ma -i C:\Dumps configures procdump.exe to automatically perform a full process memory dump any time a user-mode process crashes on the machine, and places it in the C:\Dumps directory.

This will catch a crashing Windows service as well, unless the developer of the service specifically wrote the service to do its own exception handling and avoid being caught by debuggers, which is pretty rare. (And even then, procdump can be configured to dump on first-chance exceptions too.)

PS: You might see the "service terminated unexpectedly" message if the service actually crashed, but you might also see the same message if the service just felt like it needed to exit without cooperating with the Service Manager like it's supposed to. In that case, the developer of the service was just a bad developer, and since there was no actual crash, neither WER nor procdump will help you.