How to get a dump of a specific process in Windows

A process running on a Windows workstation crashes.

The Windows Application event log is reporting that a process has terminated unexpectedly.

A process running on a Windows workstation appears hung.

The Windows Error Reporting (WER) system should already be capturing the process crash events, and will be writing mini-dumps and other report information to the "C:\ProgramData\Microsoft\Windows\WER\" subdirectories.  Collecting and submitting these existing mini-dumps for analysis can sometimes provide useful clues or confirmation of a previously-resolved issues.  However, these default mini-dumps are insufficient in many situations for making a complete analysis for why a process crashed.

Collecting a "Full" process dump of the crash will provide a dump containing all process code and memory, rather than only small critical sections of process structures and memory immediately adjacent to the site of the crash.  To have WER write a full process dump during future crashes, the following registry key and value must be created:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps]

"DumpType"=dword:00000002

Note the "LocalDumps" subkey typically does not exist by default, and must be created in addition to the actual "DumpType" DWORD value within that subkey.

This will cause future crashes captured by WER to have full process dumps written instead of just mini-dumps.  The full process dumps caused by the "DumpType" configuration are not written to "C:\ProgramData\Microsoft\Windows\WER\", and instead by default are written to a "%LOCALAPPDATA%\CrashDumps" directory which is relative to the current user profile.

So if a normal desktop application crashes, the full process dumps will be written to the "C:\Users\<username>\AppData\Local\CrashDumps\" directory for the interactive user who was logged on.  If a Windows service crashes (such as Novell Client's XTSVCMGR.EXE process) or other program not "running as a user" crashes (such as the Microsoft LogonUI.exe user interface), then the full process dumps will be written to "C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps\" which is the user profile area used by Windows system components.

In some cases, such as when a crash occurs before the user has logged on, the default location may be ambiguous, so it is desireable to specify a specific directory for the crash dump. To do this, create a "DumpFolder" REG_EXPAND_SZ value and set it to "C:\ProgramData", so that the process dump will be written to this directory.  

After establishing the "DumpType" configuration, restart Windows to be sure WER will be using the new "DumpType" configuration, and then reproduce the issue or wait for the crash to happen again, at which point a full process dump should now be captured by WER.

IF THE PROCESS HAS NOT CRASHED, and is only hung and non-responsive:

With the issue duplicating, open Task Manager by pressing CTRL-ALT-DEL and selecting "Task Manager", or by running TASKMGR.EXE from the "Run" dialog or command line.  If necessary, use the "Show processes from all users" option in Task Manager to show processes that are running for other users or for Windows services.  Note that in Windows 7 and earlier the processes are listed on the "Processes" tab, and in Windows 8 and later they are listed on the "Details" tab.

Once you can see the hung process in Task Manager, right-click on the process and select "Create dump" to write a full dump of this process.  Dump files created by Task Manager are typically written to the TEMP directory of the user who is running Task Manager, e.g. "C:\Users\<username>\AppData\Local\Temp\".  Task Manager will display the dump file name and location once the dump has been written.

In some cases, the dump of a 32-bit process captured using the 64-bit Task Manager can be difficult to analyze due to the involved WOW64 layer revealed by the natively 64-bit dump.  When knowingly capturing a dump of a 32-bit process running on 64-bit Windows (as indicated by "*32" behind the image name listed in Task Manager), use the following steps to write a 32-bit dump instead of a 64-bit dump:

1.  Instead of running TASKMGR.EXE normally, launch a Command Prompt using "Run as Administrator."  

2.  Switch to the C:\Windows\SYSWOW64\ directory instead of the default C:\Windows\SYSTEM32\ directory.  

3.  From the SYSWOW64 folder in the Command Prompt, run TASKMGR.EXE which is the 32-bit version of TASKMGR.EXE.  

4.  From the 32-bit Task Manager window, now use the previously described steps of right-clicking and selecting "Create dump" on the hung process.  By using the 32-bit version of TASKMGR.EXE, a 32-bit dump of the process will be created.  

Note: There can be difficulties in attempting to launch the 32-bit TASKMGR.EXE using a 64-bit Windows Explorer, so the Command Prompt method described is the recommended approach.

Or, you can download the Microsoft Process Explorer utility to create the dump, instead of using Task Manager:

1. Download the current Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) from Microsoft (http://technet.microsoft.com/en-us/sysinternals/).

2. Launch Process Explorer using "Run as Administrator" so that it will have permission to see all processes.

3. Find the hung process(es) and right-click to select "Create Dump -> Create Full Dump".  

Note Process Explorer creates a 32-bit dump of 32-bit processes, even when the 64-bit version of Process Explorer is running.

1. In "Event Viewer" go to "Windows Logs", right-click "Application" or "System", and select "Save all events as".)  Choose the native .EVTX file format