An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg

Once a Windows application starts crashing “only occasionally,” there are plenty of situations where logs alone are not enough to track it down.

The really painful cases look like this.

• It only happens in the customer’s environment
• You have the exception message, but not enough context about the caller
• It involves not just the managed side of C# / .NET, but also COM, P/Invoke, native DLLs, and vendor SDKs
• It only crashes after long hours of continuous operation

This is where crash dumps shine. If you capture the process state at the moment of the crash into a file, you can later read the exception code, the stack of the crashing thread, the loaded modules, and part or all of the memory.

On Windows, the easiest way to think about it is in this order: start with WER LocalDumps, add Sysinternals ProcDump when needed, and reach for MiniDumpWriteDump only when you want even more control. In this article, we lay out the first steps of crash dump collection, assuming Windows desktop applications, resident applications, Windows services, equipment-integration tools, and the like.

1. The Conclusions First

Let’s start with the points you want to lock in first.

• The safe first move is to configure WER LocalDumps per application. With no extra tools, you get a dump saved locally after a crash.
• Use ProcDump for low-reproduction-rate field investigations, or when you also need first chance exceptions / hangs.
• Treat custom collection as the last resort — that is about the right priority. Consider MiniDumpWriteDump only once you actually need it.
• Just as important as the dumps themselves is keeping the PDBs and the shipped binaries. A dump alone, without symbols, dramatically reduces how much you can read.
• Full dumps are powerful, but their size and the risk of including confidential data are just as powerful. Decide the storage location, retention count, access rights, and sharing procedure up front.

At the introductory stage, the recommended setup usually lands around here.

In short: WER first, then ProcDump, then custom collection last. Start in the reverse order and your design almost always ends up heavier than it needs to be.

2. What a Crash Dump Tells You

A crash dump is a “snapshot of that moment.” It is less like a security camera and more like a still photo of an accident scene.

That makes this kind of information quite easy to get.

• Which exception code the crash occurred with
• Which thread crashed
• The call stack at that point
• The modules that were loaded
• Depending on how much memory was included, heap state and the contents of objects

On the other hand, some things tend to be missing from a dump alone.

• The timeline leading up to the crash
• A growth trend from hours earlier
• External state involving communication or equipment
• The most recent input and the business context

So in practice, the basic approach is: do not try to finish the job with the dump alone — combine it with logs and heartbeats.

3. The Big Picture of Collection Methods

For dump collection on Windows applications, there are four methods you want to know at the introductory stage.

For beginners, the most important thing is this: before deciding “which tool to capture with,” decide “under what conditions,” “to where,” and “at what size.”

4. The Recommended First Step Is WER LocalDumps

4.1 The Registry Values to Look at First

Windows Error Reporting (WER) has LocalDumps, which saves user-mode dumps locally after a crash. Since you do not have to distribute any extra tools, it is a very approachable first move.

The base key is here.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

You can put a global configuration here, but in practice it is easier to manage with per-application subkeys.

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

There are three values to look at first.

4.2 An Example of Per-Application Configuration

For example, if you want to keep up to 10 full dumps for MyApp.exe in C:\CrashDumps\MyApp, you can start with the following.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

This example has four key points.

• It is scoped to MyApp.exe, not global
• The output is separated into a dedicated folder
• It starts with full dumps
• The retention count is capped at 10

4.3 Verifying That a Dump Was Captured

Once the configuration is in place, it is safer to go through a full capture at least once in a test environment rather than waiting for the crash to occur naturally in production.

There are four things to check.

1. Does a .dmp file appear in the expected folder?
2. Is the size in line with operational expectations?
3. Can it be opened in WinDbg?
4. Is the crash visible in the Application log in Event Viewer?

5. When to Use ProcDump

WER is often enough, but there are situations where ProcDump comes in handy.

• You want to avoid a permanent registry setting
• You want to monitor only a process that is already running
• You want to monitor starting only from the next launch
• You want to see first chance exceptions
• You want to capture a hang
• You want to capture based on performance counters or other conditions

5.1 Frequently Used Options

Narrowing things down to what you actually use at the introductory stage, knowing these ProcDump options will take you a long way.

5.2 Representative Command Examples

Full dump of an already-running process on unhandled exception

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

Wait for the next launch, then full dump on unhandled exception

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

Launch the process yourself and monitor it directly

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

Also capture first chance exceptions

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

Capture a hang

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 Why -i Should Not Be Your First Move

ProcDump can also be registered as a postmortem debugger with -i. This is powerful, but it changes machine-wide crash-time behavior, which makes it a little heavy as the very first step at the introductory stage.

So it is easier to start with per-application WER configuration or with ProcDump’s -w / -x / PID targeting.

6. How to Think About Custom Collection with MiniDumpWriteDump

Custom collection is a good fit in situations like these.

• You want a “Save diagnostic information” button in the UI
• You want to bundle logs, settings, and trace IDs together with the dump
• You want to include related child or helper processes as well
• You want to apply your own masking or compression before uploading

The central API here is MiniDumpWriteDump.

That said, it has some quirks. At the introductory stage, the two points you especially do not want to get wrong are these.

1. If at all possible, call it from a process other than the one being dumped
2. Treat the DbgHelp family of APIs as single-threaded

7. Choosing Between Minidumps, Full Dumps, and In-Between Sizes

A lot of people get stuck here. Here is how we choose in practice, in table form.

The recommendation for beginners is quite simple.

• Full dumps on dev / test machines
• In customer environments, choose mini or full based on operational constraints
• If you suspect memory corruption, native DLLs, COM, P/Invoke, or state anomalies after long-running operation, lean toward full

8. What to Decide Up Front Operationally

Dump collection trips up far more often on operations than on implementation. Here is what you want to decide in advance.

8.1 How to Retain PDBs and Binaries

This is the single most important thing.

• The exact version of the shipped EXE / DLL
• The PDBs corresponding to that version
• Which commit / which build pipeline produced it
• Version information for the installer and distributed artifacts

8.2 Where to Write Dumps, and How Many to Keep

Full dumps get quite large. It is safer to decide the output location and retention policy from the start.

• Do not leave dumps sitting directly on the system drive
• Separate them into a dedicated folder
• Cap the count with DumpCount or -n
• Separate long-term storage from initial intake

8.3 Who Is Allowed to Look

Full dumps may contain confidential or personal information.

• Plaintext configuration
• Connection strings
• Tokens and credentials
• Business data that was being handled just before the crash
• File paths and user names

So along with designing “how to capture,” you also need to decide “who is allowed to touch the dumps.”

9. The Shortest Path to Analysis Once You Have a Dump

After capturing a dump, the first steps are surprisingly plain.

9.1 Install WinDbg

Today’s WinDbg is easy to install from the Microsoft Store or via winget.

winget install Microsoft.WinDbg

9.2 Open the Dump

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

9.3 Set Up Symbols

First get Microsoft’s public symbols working, then add the location of your own PDBs.

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4 Start with the Automated Analysis

!analyze -v

From there, check in order:

• Which exception code it is
• What the faulting module is
• How far your own code is visible on the stack
• Whether there are suspicious waits or blockages on threads other than the exception thread

10. Common Pitfalls

10.1 You Got the Dump, but There Are No PDBs

This one is extremely common. The dump collection itself succeeded, but you are short on material to read it with. Put the PDB retention design in place at the same time as the collection setup.

10.2 Not Checking the ACL on DumpFolder

With services or privilege-separated processes, this is an easy place to whiff. Verify first that the process can actually write there.

10.3 Continuously Writing Full Dumps to the System Drive on a Production Machine

This is the classic disk-space incident. Put retention limits and output-folder separation in from the start.

10.4 Trying to Cover Hangs Entirely with WER Alone

WER LocalDumps is strong primarily for crashes. For hangs and first chance exceptions, ProcDump is often the better fit.

10.5 Leaving -e 1 On Permanently and Drowning in Exceptions

First chance exceptions are useful, but they are simply numerous. Realistically: cap the count, enable it only for short periods, and limit the target.

11. Summary

Crash dumps are a remarkably strong observation point for failures with low reproduction rates. Especially when a Windows application involves COM, P/Invoke, native DLLs, or long-running operation, it is worth deciding from the start “what will be left behind when it crashes.”

The recommended order is simple.

1. First, set up WER LocalDumps per application
2. Add ProcDump if needed
3. If you want even more control, use MiniDumpWriteDump from a separate process

Proceed in this order and you are unlikely to go far wrong.

12. References

• [Collecting User-Mode Dumps - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps)

• [ProcDump v11.1 - Sysinternals

  Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump)

• [MiniDumpWriteDump function (minidumpapiset.h) - Win32

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/nf-minidumpapiset-minidumpwritedump)

• [User-mode dump files - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files)

• [Analyzing a User-Mode Dump File - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file)

• [Install the Windows debugger - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/)

• [Symbol path for Windows debuggers - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path)

• [!analyze (WinDbg) - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-analyze)

• [Troubleshoot processes by using Task Manager - Windows Server

  Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-server/support-tools/support-tools-task-manager)

• [Enabling Postmortem Debugging - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging)

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.