How to read a .dmp file online

1. Find the crash dump on your PC

When small-dump recording is enabled — the Windows default — every blue screen writes a dated .dmp file. Windows can keep two quite different things, and the difference matters more than it looks:

The minidump is the more useful file for most investigations, not despite being small but because Windows keeps every one of them. A single crash rarely proves anything; four crashes that all name the same driver do. If the Minidump folder is empty, small-dump writing is off — the two sections below turn it on.

2. Windows 10: enable and locate minidumps

1. 1

   Check the folder first

   Browse to C:\Windows\Minidump. Each blue screen leaves one dated .dmp file, typically 1–3 MB. If files are already there, skip to step 3.

2. 2

   Turn on small dumps if it is empty

   Press Win+R, run sysdm.cpl, then Advanced → Startup and Recovery → Settings. Set Write debugging information to Small memory dump (256 KB). The next crash will be recorded; nothing can recover a crash that happened while this was off.

3. 3

   Copy the newest file out

   Reading the folder usually needs administrator rights, and some security software locks files in place. Copy the most recent .dmp to your Desktop and work from the copy.

3. Windows 11: the same folder, a different default

Windows 11 writes crash dumps to the same C:\Windows\Minidump path, but its default Write debugging information setting is Automatic memory dump. That produces a large MEMORY.DMP and, on most configurations, a minidump alongside it — but the automatic setting also lets Windows shrink the paging file, which can leave you with no dump at all after a crash early in boot.

To be certain a readable file is captured, open sysdm.cpl → Advanced → Startup and Recovery → Settings and choose either Automatic memory dump (keeps the minidump too) or Small memory dump (256 KB) explicitly. Leave Overwrite any existing file unticked if you want the rolling minidump history.

Windows 11's stop screen shows a QR code and a stop-code name and nothing else. The name alone is a symptom label — the same code appears for a dozen unrelated causes. The .dmp file is where the distinguishing evidence lives, which is why reading it is worth the five minutes.

4. Open the .dmp file without WinDbg

1. 1

   Copy the newest file

   Sort C:\Windows\Minidump by date and copy the most recent .dmp to your Desktop.

2. 2

   Drop it on the analyzer

   Open dumpreader.com and drag the file onto the page. It uploads over HTTPS and is parsed in server memory; the dump bytes are discarded with the response.

3. 3

   Read the decoded report

   You get the stop code and its four parameters, a confidence-rated probable culprit, the call stack, the loaded-driver list and system details — the same evidence a debugger surfaces, laid out for reading.

5. What is actually inside a minidump

Knowing what the file does and does not contain explains most of the frustration people have with crash analysis. A 256 KB minidump is not a memory image; it is a targeted selection.

• The bug check record

  The stop code and its four parameters. The parameters are the most under-used field in the whole file: for 0x1A the first parameter names the memory-manager subtype, and for 0x7F it identifies the processor trap.

• The crash context

  The processor register state captured at the fault — instruction pointer, stack pointer and the general registers. The instruction pointer is what allows a module to be named directly rather than guessed.

• The loaded-module list

  Every driver and kernel module resident at crash time, with its base address, image size and timestamp. This is what turns a raw address into a name.

• A slice of the kernel stack

  Only the crashing thread's stack, and only part of it. Anything that ran and returned before the fault is already gone.

• Small bounded memory regions

  A little memory around the interesting addresses. Not the heap, not user-mode process memory, not the pages that were corrupted an hour earlier.

• What is not there

  No history. A minidump is a photograph of the moment of death, not a recording of the illness — which is exactly why the culprit is sometimes unknowable from one file.

6. How to read the report

Work outward from the strongest evidence, not from the first familiar name you recognise.

1. 1

   Start with the stop code and its parameters

   The name points at a category — a driver fault, a memory-manager inconsistency, or hardware. Look it up in the stop-code reference, then read the four parameters, because they usually narrow a broad code to a specific subtype.

2. 2

   Check the culprit confidence, not just the name

   High means the kernel named a driver directly, or the faulting instruction address fell inside a loaded module's address range — that is arithmetic, not inference. Medium means a module appeared early on the stack and was not excluded as common core noise. Low means only core Windows modules are visible and the dump cannot attribute the fault.

3. 3

   Read the stack as a sequence, not a suspect list

   Frames near the top ran most recently. A resolved symbol name means a public symbol matched an address; an unresolved frame is an address inside a module with no public symbols, which is normal for third-party drivers and is not itself suspicious.

4. 4

   Corroborate across several dumps

   Open three or four files from C:\Windows\Minidump. A driver that appears in one is a coincidence; one that appears in all of them, under different stop codes, is a finding.

7. The three ways a culprit call goes wrong

Automated dump analysis — this site's included — fails in predictable ways. Knowing them is the difference between fixing a machine and replacing parts at random.

8. When you need WinDbg or a larger dump

An online minidump reader answers the common case quickly. It cannot answer everything, and pretending otherwise wastes your time. Reach for the Windows debugger and a kernel or complete dump when:

• Repeated crashes name a different suspect every time, with no hardware fault found.
• The stop code is 0x124 WHEA_UNCORRECTABLE_ERROR — the detail lives in a hardware error record that needs a full dump to interpret.
• You suspect pool corruption and need Driver Verifier's special pool, which changes what the crash captures in the first place.
• The stack is missing or obviously truncated, or the dump reports its own data as unavailable.
• A wrong diagnosis would cost data or hardware — a server, a RAID controller, or anything you cannot simply re-image.

Microsoft references: Small Memory Dump files and Varieties of kernel-mode dump files.

Common questions