Capture Per-App Crash Dumps on Windows 11/10 with WER LocalDumps Registry Settings

This is especially useful for developers, IT administrators, and power users chasing intermittent crashes in line-of-business software, development tools, or legacy applications. The configuration described here applies to user-mode application crashes, not Windows blue-screen kernel dumps.

Microsoft documents this feature as LocalDumps. It has been supported since Windows Vista SP1 and Windows Server 2008, requires administrator privileges, and is controlled under the HKEY_LOCAL_MACHINE Registry hive.

What LocalDumps captures—and what it does not​

A crash dump is a snapshot of an application at failure time. Depending on the selected dump type, it can include:

• The crashing thread and call stack
• Loaded modules and exception information
• Memory used by the application
• Heap contents, which may contain documents, passwords, tokens, or other sensitive data

That last point matters. A full dump is a superb forensic artifact and a terrible thing to leave in a world-readable folder.

LocalDumps is designed for applications that crash under normal Windows Error Reporting handling. Microsoft notes two important limitations:

• Applications that implement their own custom crash-reporting system may not produce a LocalDumps file.
• WER does not collect a LocalDumps dump when automatic debugging for application crashes is configured. In other words, a postmortem debugger configured to launch automatically can change the crash-handling path.

For most targeted troubleshooting, configure a dump only for the executable you actually need. That keeps storage use and privacy exposure from becoming a full-time hobby.

Before you begin​

You will need:

• An account with local administrator rights
• The exact executable filename, such as ContosoApp.exe
• A local folder with sufficient free disk space
• Permission for the crashing application’s user account to write to that folder
• A reproducible crash, if you intend to validate the configuration immediately

Do not use the application’s friendly product name for the Registry key. WER matches the executable filename. If Task Manager lists ContosoApp.exe, that is the name to use.

For a conventional desktop app, a dedicated folder such as C:\CrashDumps\ContosoApp is a sensible choice. Avoid a broadly shared directory. Full dumps can be very large—sometimes approaching the memory footprint of the crashed process.

Create a per-app LocalDumps configuration​

The target Registry path is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\<ApplicationName>.exe

For an application named ContosoApp.exe, the complete path is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ContosoApp.exe

A per-app key overrides any global values placed directly under LocalDumps. That is precisely why it is the safer default: one troublesome application gets a black box recorder, while everything else carries on normally.

Method 1: Configure it with Registry Editor​

1. Press Windows + R, type regedit, and press Enter.
2. Approve the User Account Control prompt.
3. Navigate to:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting
4. If a LocalDumps key does not exist, right-click Windows Error Reporting, select New > Key, and name it:
   LocalDumps
5. Right-click LocalDumps, select New > Key, and name it with the exact executable filename:
   ContosoApp.exe
6. Select the new application key and create the following values.

To create DumpFolder correctly, choose New > Expandable String Value—not an ordinary String Value—and enter the destination folder path.

Create the folder before testing. Also ensure the account running the application can write there. If the application runs as a service, this is where things become entertaining in the least entertaining way: the service account, not your interactive administrator account, must have write access.

Choose the right dump type​

WER supports three DumpType values:

Start with a minidump for routine crashes​

Set:

DumpType = 1

Microsoft identifies this as the default LocalDumps type. A minidump is generally the sensible starting point because it captures the crash context while limiting disk consumption.

It may not, however, contain enough memory to diagnose heap corruption, inspect a specific object, or prove why one thread supplied bad data to another. A minidump can tell a compelling story, but sometimes it arrives with several pages missing.

Use a full dump when the issue demands it​

Set:

DumpType = 2

A full user-mode dump includes the application’s process memory. This is often the right choice when:

• A developer requests a “full process dump” or “heap dump”
• The crash appears related to data corruption or native code
• A minidump identifies the failing module but cannot explain the root cause
• The problem is intermittent and difficult to reproduce

Treat full dumps as sensitive operational data. Store them on an encrypted, access-controlled local volume where possible, and delete or archive them according to your organization’s incident-handling rules.

Custom dumps are for specialists​

Set:

DumpType = 0

Then add CustomDumpFlags as a REG_DWORD using a bitwise combination from the Windows MINIDUMP_TYPE options. Microsoft’s documented default custom combination is 0x121, representing data segments, unloaded modules, and process/thread data.

Unless you already know why a particular minidump flag is necessary, use 1 or 2. Custom flags are powerful, but so is a table saw.

Configure LocalDumps from an elevated command prompt​

If you prefer a repeatable setup for a test lab or support runbook, open Command Prompt as administrator and run:

mkdir C:\CrashDumps\ContosoApp

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ContosoApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\ContosoApp" /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ContosoApp.exe" /v DumpCount /t REG_DWORD /d 5 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ContosoApp.exe" /v DumpType /t REG_DWORD /d 2 /f

Replace every instance of ContosoApp.exe with the target executable’s actual filename.

This example retains five full dumps. Adjust that number to suit available disk capacity and the expected crash rate. Microsoft states that when the limit is exceeded, WER replaces the oldest dump in the configured folder.

Verify that Windows saved a dump​

After the configuration is in place:

1. Confirm that the target executable name in the Registry matches the running process exactly.
2. Confirm that the configured folder exists.
3. Confirm that the application’s user or service account can write to it.
4. Reproduce the real crash through normal testing, if it is safe to do so.
5. Check the dump folder after the application closes unexpectedly.

A successful capture normally produces a .dmp file with the executable name in it, such as:

ContosoApp.exe.1234.dmp

WER evaluates LocalDumps settings after the application crashes and before Windows allows the process to terminate. The dump should therefore appear shortly after the failure.

If no dump appears, check these common causes:

• Wrong key name: ContosoApp is not the same as ContosoApp.exe.
• Wrong Registry hive: LocalDumps settings are supported under HKEY_LOCAL_MACHINE, not HKEY_CURRENT_USER.
• Folder permissions: The crashing account lacks write access.
• Custom crash handler: The application bypasses the normal WER crash path.
• Automatic debugging: An automatically launched postmortem debugger can prevent LocalDumps collection.
• No crash occurred: A hang, graceful exit, or application-level error may not create the kind of unhandled failure WER captures.

For service crashes that use the default dump location rather than a custom DumpFolder, remember that the effective local app-data location depends on the service identity. System, Local Service, and Network Service do not use your personal profile folder.

Open the result in WinDbg​

A dump file is evidence, not a verdict. To inspect it, open the file in WinDbg and run:

!analyze -v

Microsoft’s WinDbg documentation describes !analyze -v as the standard starting point for detailed exception analysis. Focus first on:

• The exception code
• The faulting module
• The crashing thread
• The stack trace
• Whether third-party DLLs appear near the failure

Do not leap straight from a module name to blame. A crash inside a Windows DLL often means that another module passed it invalid data earlier. Likewise, a security product, shell extension, overlay tool, or injected monitoring DLL can be present without being the root cause. Debugging is less “find the nearest DLL and point dramatically” and more “follow the evidence until it stops arguing.”

For internally developed software, matching symbol files (.pdb) are essential for meaningful function names and source-level diagnosis. For commercial software, provide the dump to the vendor only through an approved support channel, and review it first for sensitive information.

Remove the configuration safely​

When the investigation is complete, remove the per-application key rather than deleting the entire LocalDumps branch. Other applications or administrators may have legitimate configurations there.

From an elevated Command Prompt:

reg delete "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ContosoApp.exe" /f

Or, in Registry Editor, right-click the ContosoApp.exe key and select Delete.

Then archive or securely delete the collected dump files according to their sensitivity and retention requirements. Removing the Registry key stops future collection; it does not remove dumps already on disk.

The practical configuration to remember​

For most app-crash investigations, use this formula:

• Per-app key: ...\LocalDumps\AppName.exe
• Folder: a local, access-controlled directory
• Dump count: 3 to 10, depending on disk space
• Dump type: start with 1; use 2 when an engineer needs heap or full-memory evidence
• Cleanup: delete only the application-specific key when finished

That turns Windows Error Reporting from a vague “the app stopped working” moment into a reusable diagnostic workflow. When the next crash happens at 2:13 a.m., you may not have the answer—but at least the culprit has left a proper trail.