How to Read a Windows Crash Dump File

When Windows crashes it writes a file describing what the machine was doing at that instant. Almost nobody reads it, which is why most crash troubleshooting is guesswork. Reading one is genuinely a fifteen-minute job, it is free, and it converts a vague stop code into a specific driver name more often than not.

Updated 2026-07-28

Where the dump files are

Windows writes two kinds of dump. The small one, a minidump, lands in:

C:\Windows\Minidump\

Files are named by date, like 072826-9187-01.dmp. Each crash produces one, and they are small enough that Windows keeps many.

The larger one, a kernel or complete memory dump, is a single file that gets overwritten on each crash:

C:\Windows\MEMORY.DMP

For most purposes the minidump is enough and easier to work with. Start there.

No files at all?

Open System Properties, go to Advanced, then Startup and Recovery, and set Write debugging information to Small memory dump or Automatic memory dump. Make sure the page file is on the system drive and system-managed. If dumps still never appear despite repeated crashes, treat that as evidence in itself - it usually means the machine is failing before it can finish writing one, which points at hardware.

Installing WinDbg

WinDbg is Microsoft's debugger and it is free. The current version is in the Microsoft Store - search for WinDbg and install it. It is also available as part of the Windows SDK if you prefer, but you only need the Debugging Tools component.

You do not need to configure symbol paths by hand any more. Recent versions resolve Microsoft symbols automatically the first time you run an analysis. The first run downloads several hundred megabytes, so it takes a few minutes; subsequent runs are fast.

Opening the dump and running the analysis

Launch WinDbg, choose File, then Open dump file, and pick the newest .dmp from the Minidump folder. When the command prompt appears at the bottom, type:

!analyze -v

Press enter and wait. The first run can take several minutes while symbols download. What comes back is long, and most of it is noise. There are only five things worth reading.

The five lines that matter

1. The bugcheck name and code. Near the top, something like SYSTEM_SERVICE_EXCEPTION (3b). This is the stop code, and it tells you which category of failure you are in.

2. The arguments. Listed as Arg1 through Arg4. These are the bugcheck parameters, and their meaning is specific to each stop code - the per-code pages on this site explain what each one holds. On several codes the first argument alone narrows the diagnosis dramatically.

3. MODULE_NAME and IMAGE_NAME. The component the debugger believes is responsible. A third-party .sys file here is the single most useful thing in the whole output.

4. PROCESS_NAME. What was running. Often System, which tells you nothing, but on codes like CRITICAL_PROCESS_DIED it is the entire diagnosis.

5. STACK_TEXT. The call stack - the chain of functions that led to the crash, most recent first. Read downward past the Microsoft entries looking for anything that is not nt! or ntoskrnl. Third-party drivers appear here even when the debugger blames something else.

What to trust, and what not to

This is the part that most walkthroughs skip, and it is where people go wrong.

!analyze -v makes an educated guess. It is frequently right and it is sometimes confidently wrong. Specifically:

ntoskrnl.exe is almost never the culprit. It is the Windows kernel, and it appears because it was executing when the fault surfaced. The same applies to ntfs.sys, dxgkrnl.sys and tcpip.sys - these are usually the victim, not the offender. Read further down the stack.
Memory corruption produces misleading names. If bad RAM corrupts a pointer, the driver that innocently dereferences it gets blamed. This is why comparing several dumps matters so much.
A driver named once is a hypothesis. A driver named four times is a finding.

The comparison test

Open three or four dumps from different crashes and compare MODULE_NAME across them. The same module every time points at that driver. A different module each time is the signature of memory corruption - and no amount of driver reinstalling will help. This single comparison is worth more than any individual dump.

A few commands worth knowing

!analyze -v covers most cases, but a handful of others earn their place:

Command	What it does
lm t n	Lists loaded modules with timestamps. Useful for spotting a driver that is years out of date.
!errrec <address>	Decodes a WHEA error record. On bugcheck 0x124, pass the address from Arg2 and it tells you which hardware component reported the fault - the most valuable command on that stop code.
!irp <address>	Displays an I/O request packet. On bugcheck 0x9F with Arg1 = 3, pass the address from Arg4 to see which driver was holding up the blocked request.
!devstack <address>	Shows the device stack for a physical device object, naming the driver behind it.
dx KiBugCheckDriver	Displays the driver name Windows itself identified, when it managed to identify one.
!process 0 0	Lists running processes at the time of the crash.

What to do with a driver name

Once you have a name, search it. Most .sys files identify their vendor immediately, and the common offenders are recognisable: nvlddmkm.sys is NVIDIA's display driver, amdkmdag.sys is AMD's, iaStorA.sys is Intel Rapid Storage, rt640x64.sys is a Realtek network driver.

Then, in order: install the vendor's current version rather than whatever Windows Update supplies; if the crashes started after an update, install the previous release instead; and if the driver belongs to software you do not use, uninstall it entirely.

If the dump names nothing useful across several crashes, that is itself informative - it points away from a single misbehaving driver and toward memory or the board. At that stage testing memory is a better use of an evening than more driver work.

Frequently asked

Do I need to set a symbol path?

Not with current WinDbg versions - they resolve Microsoft symbols automatically on first use. If you are on an older build and see errors about missing symbols, set the path with .sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols and then run .reload. Note that symbols for third-party drivers are generally not published, so you will see addresses rather than function names for those - which is normal and does not prevent identification.

Is BlueScreenView good enough instead?

It is fine for a quick look and it is far easier to install. What it gives you is essentially the module list and the stop code, which answers the simple cases. What it cannot do is decode bugcheck parameters, walk the stack, or run commands like !errrec - and those are exactly what you need on the harder codes. Use it for triage, WinDbg when triage is not enough.

The dump only names ntoskrnl.exe. Is that a dead end?

Not quite. It means the debugger could not attribute the fault to a third-party module, which happens for two very different reasons: the crash genuinely originated in kernel code executing on behalf of something else, or the data it was working with had already been corrupted. Read the STACK_TEXT block for any non-Microsoft entry, and compare several dumps. If nothing third-party ever appears, shift attention to memory and the machine's stability settings.

How many dumps should I look at?

At least three, if you have them. A single dump tells you what happened once. Three or four tell you whether the pattern is consistent, and consistency is what separates a driver bug from hardware corruption. If you only have one crash so far, read it - but hold the conclusion loosely until it repeats.