A production server crashes, and the event log gives you an “Application Error” with an exception code and nothing else. No dump file, no call stack, no thread state—just a timestamp and a headache. Proactive crash dump collection fixes that. You tell Windows to automatically write a minidump or full dump the moment an unhandled exception tears down a process, and you stop guessing. Here I’ll walk through the exact setup I use in my own debugging work: Windows Error Reporting local dumps and the registry keys that drive them.
Why Proactive Collection Matters
Reactive debugging is a scramble. You wait for a crash, then try to attach a debugger or launch ProcDump after the fact. If the failure is intermittent—or worse, happens under load at 3 a.m.—you miss it. Proactive collection hands you a dump the instant the exception goes unhandled. Call stack, thread state, heap details, all frozen. For .NET apps, a minidump with heap is usually enough to pull the exception object and managed stacks using WinDbg or dotnet-dump. Native crashes can be trickier; a full dump might be the only way to catch heap corruption. Get the collection in place ahead of time, and an opaque failure turns into a clean post-mortem.
Windows Error Reporting Local Dumps
Windows Error Reporting ships with a feature called LocalDumps. No external tools, no background service—just a registry key. You set a few values to control dump type, output folder, and file naming, and Windows takes care of the rest. It works on Windows Server 2008 onward, including Server Core where you can’t run a GUI debugger.
Registry Key Location
The key is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
If LocalDumps isn’t there, create it. You can do it through regedit, but a PowerShell script is cleaner—especially when you’re provisioning a fleet of servers.
Global Dump Settings
Under the LocalDumps key, three values steer the behavior for every crashing process. Add them as REG_DWORD or REG_EXPAND_SZ as noted:
- DumpFolder (REG_EXPAND_SZ): Where dumps land. I often stick with %ALLUSERSPROFILE%\Microsoft\Windows\WER\LocalDumps, but you can point it anywhere the crashing process’s account can write.
- DumpCount (REG_DWORD): How many dumps to keep. Older files roll off first-in, first-out. Ten is a reasonable number.
- DumpType (REG_DWORD): 0 = custom dump, 1 = minidump, 2 = full dump. For .NET debugging a minidump normally suffices; native heap corruption might demand a full dump.
Per-Application Overrides
You don’t have to treat every process identically. Create a subkey under LocalDumps named after the executable—including the .exe extension—and set DumpFolder, DumpCount, and DumpType there. For example, a subkey called w3wp.exe applies only to IIS worker processes. This is handy when one service is giving you grief and you want full dumps for it while keeping minidumps for everything else.
PowerShell Script for Deployment
Clicking through regedit on dozens of servers is a recipe for drift. A PowerShell script, pushed during deployment or via Group Policy startup, locks the settings in place. The script below creates the LocalDumps key, sets global options, adds a per-application override for w3wp.exe, and ensures the dump folder exists.
$localDumpsPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
$dumpFolder = "D:\Dumps"
# Create the key if missing
if (-not (Test-Path $localDumpsPath)) {
New-Item -Path $localDumpsPath -Force | Out-Null
}
# Global settings
Set-ItemProperty -Path $localDumpsPath -Name "DumpFolder" -Value $dumpFolder -Type ExpandString
Set-ItemProperty -Path $localDumpsPath -Name "DumpCount" -Value 10 -Type DWord
Set-ItemProperty -Path $localDumpsPath -Name "DumpType" -Value 1 -Type DWord
# Per-application override for IIS worker process
$w3wpPath = Join-Path $localDumpsPath "w3wp.exe"
if (-not (Test-Path $w3wpPath)) {
New-Item -Path $w3wpPath -Force | Out-Null
}
Set-ItemProperty -Path $w3wpPath -Name "DumpFolder" -Value $dumpFolder -Type ExpandString
Set-ItemProperty -Path $w3wpPath -Name "DumpCount" -Value 5 -Type DWord
Set-ItemProperty -Path $w3wpPath -Name "DumpType" -Value 2 -Type DWord
# Ensure the dump folder exists
if (-not (Test-Path $dumpFolder)) {
New-Item -ItemType Directory -Path $dumpFolder -Force | Out-Null
}
Write-Host "Proactive dump collection configured. Dumps will be saved to $dumpFolder"
Run it as administrator. After that, any user-mode process that hits an unhandled exception will leave a dump in the folder. The file name bundles the process name and a timestamp, so correlating with event logs is straightforward.
Verifying the Configuration
Don’t trust the setup until you see a dump land. A low-risk test: set DumpType to 1 for a non-critical service and force an unhandled exception. For managed code, a tiny console app that throws and doesn’t catch does the trick. Check the folder, then open the dump in WinDbg or dotnet-dump. If you see the exception record and a sensible call stack, the plumbing works.
Also scan the Application event log for WER events. Event ID 1001 means Windows Error Reporting caught a crash. The event details include the dump file path—useful when the ops team isn’t sure where the files are landing.
Handling Dump Size and Disk Space
A full dump of a 64-bit w3wp.exe can easily balloon past several gigabytes. One crash under load, and you’ve eaten a chunk of disk if DumpCount is generous or nobody’s watching. A scheduled task or monitoring rule that fires when the dump folder crosses, say, 50 GB will save you. DumpCount stops unbounded growth, but it doesn’t cap total size. In larger environments, give dumps their own dedicated volume so the system drive stays healthy.
Collecting Dumps for .NET Background Threads
Older .NET runtimes had a nasty habit: an unhandled exception on a background thread would silently kill the thread without tearing down the process, so WER never fired. That changed in .NET Framework 4.0, where the default is to bring the whole process down. If you’re stuck on an earlier version, add <legacyUnhandledExceptionPolicy enabled="0"> to the app config. Without it, background failures stay invisible.
Using ProcDump as an Alternative
LocalDumps is great for unhandled exceptions, but sometimes you need a dump on high CPU, memory spikes, or a particular first-chance exception. That’s where Sysinternals ProcDump shines. Run it as a persistent monitor: -ma for a full dump, -e to trigger on an unhandled exception.
procdump -ma -e -t w3wp.exe D:\Dumps\w3wp.dmp
ProcDump writes a minidump by default; -ma forces a full dump. The -t flag waits for the process if it isn’t running yet—handy for services that start on demand. The downside: ProcDump consumes a tiny amount of CPU and memory while it sits there. LocalDumps has zero runtime overhead because it hooks into the existing WER machinery. That’s why I reach for it first for plain unhandled exception capture.
Security and Access Considerations
Dump files inherit permissions from the target folder. By default, WER locks them down to SYSTEM and Administrators. If your debugging crew doesn’t have admin rights on the box, you need to add them to the local Administrators group or apply a custom ACL on the dump folder. Use icacls or Set-Acl in PowerShell to grant read access to a specific security group. Never open the permissions wide—dumps can carry connection strings, user tokens, and encryption keys straight out of memory.
Troubleshooting Missing Dumps
When a crash happens and the folder stays empty, work through this list:
- Write permissions: The account the crashing process runs under must have write access to DumpFolder. If it’s NETWORK SERVICE, grant Modify on the folder.
- WER service state: The Windows Error Reporting Service needs to be running. It’s set to Manual start by default and should trigger on demand. If someone disabled it, dumps won’t appear.
- Group Policy overrides: Domain policies can disable Windows Error Reporting or redirect it to a corporate server. Check Computer Configuration\Administrative Templates\Windows Components\Windows Error Reporting in gpedit.msc.
- Exception swallowing: The app itself might catch everything and do a tidy exit, which WER never sees. You’ll need to attach a debugger or use ProcDump with an exception filter in that case.
Automating Dump Analysis Triggers
Capturing dumps is step one. On a busy server, a new .dmp file can sit unnoticed for days. I suggest pairing the collection with a file system watcher script or scheduled task that spots new dumps and fires off an alert to your incident management system. A quick PowerShell script can monitor the folder, grab new files, and kick off an analysis pipeline—or at minimum ping the on-call engineer. That tightens the loop between crash and response.
FAQ
Can I collect dumps for kernel-mode crashes with LocalDumps?
No. LocalDumps handles user-mode process crashes only. Kernel-mode failures produce memory.dmp or minidump files governed by the system’s startup and recovery settings. Configure those under System Properties > Advanced > Startup and Recovery. Driver debugging needs a kernel debugger or a configured kernel dump path.
Will enabling LocalDumps affect server performance?
The registry keys themselves have zero impact. When a crash occurs, writing the dump hits I/O and CPU for a few seconds—same as any debugger-based capture. The process is already going down, so the overhead hardly matters. The real win is no background monitoring cost.
How do I capture dumps for custom .NET exceptions before they are caught?
If your app wraps everything in a global try-catch, WER never gets a look. For those situations, ProcDump with -e 1 -f MyCustomException triggers a dump on the first-chance occurrence of that exception type. You could also drop a vectored exception handler into your code that calls MiniDumpWriteDump before re-throwing, but that demands code changes. ProcDump with the right filters is the closest thing to a zero-code solution.
Are network paths supported for the DumpFolder value?
Microsoft’s guidance says don’t do it. WER runs in the security context of the crashing process, which might not have network access, and latency during dump writes can cause timeouts—leaving you with a truncated dump. Stick to a local drive. If you need centralized storage, run a post-processing script that moves completed dumps to a network share.
Get these configurations in place, and your Windows servers will quietly collect the evidence you need when a service falls over. The next 3 a.m. call won’t be a stab in the dark; you’ll open the dump and see exactly what the process was doing, without trying to conjure a reproduction of something that may have been degrading for hours.