Windows WER LocalDumps: Capturing User-Mode Crashes for Diagnosis
Collect bounded Windows Error Reporting user-mode dumps with per-application settings, correct folder permissions, and safe retention.
Windows Error Reporting (WER) can save a user-mode process dump locally after an application crashes. LocalDumps is useful when a failure is intermittent or a support workflow cannot attach a debugger at the right moment. It is not the same as a kernel crash dump, and it does not guarantee collection for software that implements its own crash reporting.
The feature is disabled by default and uses registry settings beneath HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. Global settings apply to applications generally; a subkey named for an executable can override them. The dump folder must be writable by the crashing process, including the actual service account when collecting a service crash.
Configure a bounded, per-application capture
Run an elevated PowerShell session and choose a folder with an explicit retention and access policy:
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe'
$folder = 'C:\ProgramData\MyApp-Dumps'
New-Item -Path $key -Force | Out-Null
New-Item -ItemType Directory -Path $folder -Force | Out-Null
New-ItemProperty -Path $key -Name DumpFolder -PropertyType ExpandString -Value $folder -Force | Out-Null
New-ItemProperty -Path $key -Name DumpType -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path $key -Name DumpCount -PropertyType DWord -Value 5 -Force | Out-Null
DumpType 1 requests a minidump; 2 requests a full dump; 0 selects custom flags. Start with the smallest dump that can answer the question. Full dumps can contain credentials, document contents, tokens, and other process memory, so restrict ACLs, encryption, transfer, and retention accordingly. A small DumpCount limits disk growth but does not replace an evidence-handling policy.
Prove that collection works
Reproduce a controlled application crash in a test environment, confirm that the dump appears in the configured location, and inspect its timestamp, size, and access permissions. Analyze a copy with WinDbg and preserve the matching executable, symbols, build identity, and crash context. A path that exists is not proof that WER could write to it under the production service identity.
Microsoft documents two important exclusions: a dump is not collected when automatic debugging for application crashes is configured, and applications with their own custom crash reporting are not supported by this feature. Check those conditions before changing unrelated WER policy. Remove the temporary key after diagnosis when continuous collection is not required.
Related:
- Windows Wait Chain Traversal: Diagnosing Hangs Without Guessing
- Windows Job Objects: Governing Process Trees, Limits, and Cleanup
Sources: