Find the crash dump, set up symbols and read !analyze -v

Find a Windows crash dump, load it in WinDbg with Microsoft symbols, and read !analyze -v: bugcheck code, faulting module, stack. Kernel BSOD dumps and application dumps.

Published 2026-10-20 by PerformanceInsights.ai

1. Find the dump

Which kernel dump Windows writes is set under System Properties → Advanced → Startup and Recovery. Application dumps are off by default; the registry key is HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps (DumpType 1 = minidump, 2 = full). Our open-source Set-WerLocalDumps.ps1 sets it up for you.

Copy the file somewhere else before you open it. A minidump is small (hundreds of KB). A full kernel dump can be as big as the machine's RAM.

2. Install WinDbg and load symbols

Without symbols, every stack frame is an offset into a module and !analyze guesses. Point the debugger at Microsoft's public symbol server, and add a local cache:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
.reload

.symfix C:\Symbols does the same in one command. For your own application or driver, add the folder holding its PDB files to the path, built from the same source as the crashing binary.

3. Run !analyze -v and read it

0: kd> !analyze -v
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arguments:
Arg1: fffff808add27150, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808adc386a6, address which referenced memory
...
MODULE_NAME:  exampledrv
IMAGE_NAME:   exampledrv.sys
STACK_TEXT: ...

• The bugcheck name and code (here 0xD1) tell you the class of failure. Each one has its own parameter meanings; see the stop code guides below.
• Arg1 to Arg4 are the four bugcheck parameters. They often hold the address to look at next.
• MODULE_NAME / IMAGE_NAME is the module !analyze blames. If it's ntoskrnl.exe or Wdf01000.sys, the real fault is usually a third-party driver further down the stack.
• STACK_TEXT is the call stack at the crash. Read it from the top down and look for the first module that isn't Windows.

For an application crash, the exception code replaces the bugcheck: c0000005 is an access violation, c0000409 a stack buffer overrun (fail-fast), c0000374 heap corruption.

4. Commands for the next step

Microsoft's reference: Analyzing a kernel-mode dump file with WinDbg and !analyze.

Common mistakes

• Blaming the module in IMAGE_NAME on sight. With pool corruption, the module that crashes is often the victim, not the one that wrote the bad memory. Driver Verifier (verifier) with special pool catches the writer at the moment it writes.
• Wrong or missing symbols. A warning like *** WARNING: Unable to verify checksum or Symbols can not be loaded means the stack below that frame may be wrong.
• Reading one dump. Different stop codes on the same machine across several dumps point to hardware (memory, overheating, power) more than to one driver.

Stop code guides: 0x9F DRIVER_POWER_STATE_FAILURE · 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL · 0x133 DPC_WATCHDOG_VIOLATION. On Linux instead? Analyze a Linux core dump.