How to Read a .dmp File and Diagnose a Blue Screen (Without WinDbg)

A Windows machine crashes mid-render. You come back to a rebooted desktop, a vague "Windows recovered from an unexpected shutdown" notice, and a file called something like 073126-9281-01.dmp that nothing on the system will open.

The standard advice is to install WinDbg, configure a Microsoft symbol server, learn the !analyze -v command, and interpret the output. That is the correct path for a driver developer. For someone who just wants to know whether to roll back a GPU driver or replace a RAM stick, it is a wall.

This guide covers how to decode a dump in a browser with DumpReader, and — the part that matters more — how to read the result without drawing the wrong conclusion from it.

Why This Matters

Blue screens have become an AI-workstation problem in a way they weren't five years ago. Running local models, long video renders, and GPU-saturating workloads all push graphics drivers, VRAM, storage filter drivers and power delivery far harder and for far longer than ordinary desktop use. Hardware and drivers that seem perfectly stable in a browser fall over an hour into a sustained load.

The dump file is the only direct evidence of what the kernel was doing at the moment it gave up. Everything else — event logs, reliability history, forum guesswork — is inference around it.

What a .dmp File Actually Contains

A crash dump is a partial snapshot of kernel memory that Windows writes at the moment it stops with a blue screen.

A 256 KB minidump holds:

• The bug check record and its four parameters
• Processor register state at the moment of the fault
• A list of loaded modules with addresses and timestamps
• The crashing thread's stack — partial only
• Small memory regions around critical addresses

And, crucially, what it does not hold: any history. As DumpReader's own guide puts it, "a minidump is a photograph of the moment of death, not a recording of the illness."

That single sentence explains most bad crash diagnoses. You are looking at the final frame, and the cause frequently happened earlier, off-camera.

Step 1: Find the Dump File

Use the minidumps. Not only are they small enough to analyse in a browser, Windows keeps every one of them — so the folder is a crash history, not just a single incident. That history is the single most valuable diagnostic asset you have, for reasons that become clear in Step 4.

MEMORY.DMP gets overwritten on every crash. One crash, no history.

Step 2: If the Folder Is Empty, Turn Minidumps On

No dumps means the setting is off or the crash never got far enough to write one.

• Windows 10: open sysdm.cpl, then Advanced → Startup and Recovery → Settings, and set Write debugging information to Small memory dump (256 KB).
• Windows 11: same path. The default is Automatic memory dump, which does produce dumps, but selecting Small memory dump explicitly is the more reliable choice if you want a per-crash history.

Do this before the next crash. Diagnosing a blue screen you have no dump for is guesswork with extra steps.

Step 3: Decode It in the Browser

Copy the newest .dmp out of C:\Windows\Minidump to your Desktop — copying avoids permission problems on the system folder — then drop it on dumpreader.com.

The file is parsed server-side and a report comes back with:

• Stop code decoding, against a reference of 150+ codes
• Culprit evidence, with a confidence rating
• Stack frames mapped to modules and symbols
• Driver inventory, including unloaded entries
• System context — Windows build, processor count, registers, memory regions
• Raw fields with file offsets, for anyone who wants to check the work

Two practical constraints. The upload limit is 32 MB, which fits minidumps easily and rules out most MEMORY.DMP files. And support is tiered by format: 64-bit kernel triage dumps (PAGEDU64, type 4) are best supported, user-mode MDMP files work, 32-bit kernel dumps get limited analysis, and complete or automatic dumps are read at header level only.

A privacy note worth being explicit about. Unlike a purely client-side tool, this one does upload — the file goes over HTTPS, is parsed in memory, and the bytes are discarded with the response, with no accounts, cookies, analytics or retention. That is a reasonable design, but a kernel dump can contain fragments of whatever happened to be resident in memory when the machine died. Upload dumps from machines you are authorised to troubleshoot, and not a customer's server without asking.

Decode Your .dmp File

Step 4: Read the Report Without Fooling Yourself

This is the part that separates a diagnosis from a guess. DumpReader is unusually blunt about its own limits, and the framing is exactly right:

Treat the result as a lead, not proof. Sometimes it can identify a strong lead; it cannot prove the cause.

Start with the stop code and its parameters

The stop code is the category. The four parameters usually narrow it to a subtype — DRIVER_IRQL_NOT_LESS_OR_EQUAL tells you a driver touched paged memory at the wrong IRQL, and the parameters tell you which address and which access type. Cross-reference against Microsoft's Bug Check Code Reference rather than the first forum thread in the search results.

Take the confidence rating seriously

A low-confidence culprit is not a weak accusation. It is the tool telling you it does not know, and acting on it anyway is how people end up reinstalling Windows over a bad RAM stick.

Read the stack as a sequence, not a suspect list

Frames near the top executed most recently. The stack is a narrative of how execution arrived at the fault, not a lineup of candidates. Unresolved frames — raw addresses with no public symbol — are completely normal for third-party drivers, which do not ship symbols to Microsoft's server.

Corroborate across several dumps

The rule that does most of the work:

A driver that appears in one is a coincidence; one that appears in all of them, under different stop codes, is a finding.

Run three or four dumps through, one after another, and compare. This is precisely why the minidump folder — which keeps everything — beats the single overwritten MEMORY.DMP.

The Four Ways Crash Reports Mislead You

The victim, not the perpetrator. A driver can fault while reading a structure that a different component corrupted minutes earlier. The one holding the gun when the music stopped gets named. This is the single most common misdiagnosis.

The bystander effect. Antivirus, VPN and storage filter drivers sit in the I/O path of nearly everything, so they show up on nearly every stack. Frequency here reflects position, not guilt.

Hardware wearing a software mask. Faulty RAM produces crashes naming a different module each time, because the corruption lands wherever it lands. Randomly varying culprits across dumps is itself the diagnosis — stop reading dumps and run mdsched.exe.

Microsoft modules taking the blame. Third-party drivers often return before their damage is detected, leaving ntoskrnl.exe or another core module executing when the fault surfaces. Windows being named usually means attribution failed.

Step 5: Know When to Escalate to WinDbg

The browser report is the fast first pass. Install the real debugger when:

• Crashes consistently name different suspects and memory has already tested clean
• The stop code is 0x124 (WHEA_UNCORRECTABLE_ERROR) — a hardware error report that needs deeper decoding
• You need Driver Verifier with special pool allocation to catch the offender in the act
• Stack data is missing or truncated
• A misdiagnosis would risk data loss or hardware damage — a wrong call on a production server is worth an hour with the proper tool

There is no shame in the escalation. A free browser report that resolves the routine 80% and tells you honestly when it cannot is doing its job.

A Sane Triage Order for a Crashing Workstation

1. Collect the history. Copy the whole Minidump folder somewhere safe before anything overwrites it.
2. Decode the newest three or four. Look for a name that repeats across different stop codes.
3. If culprits vary randomly, test the RAM. Run mdsched.exe before touching a single driver.
4. If one third-party driver repeats, deal with that driver. Update it, or roll it back to the version that predates the crashes — GPU drivers under sustained AI load are a frequent offender.
5. If only core Windows modules appear, add evidence rather than guessing. Driver Verifier under WinDbg, or a clean-boot bisect of startup drivers.
6. Re-test under the load that actually crashes it. A machine that survives idle overnight proves nothing about a six-hour render.

Frequently Asked Questions

Can I analyse a dump without installing anything? Yes — DumpReader parses the file and returns the report in the browser. No debugger, no symbol server configuration.

My dump is bigger than 32 MB. Now what? That is MEMORY.DMP. Use C:\Windows\Minidump instead, where per-crash files are 1–3 MB. If you genuinely need the full kernel dump, that is a WinDbg job.

Does the report tell me how to fix the crash? No, and neither does WinDbg. It identifies evidence — a stop code, a probable module, a stack. The fix is inference on top of that: update, roll back, remove, or replace. Anything claiming to fix a blue screen automatically is selling something.

What if the same driver appears but it is a Windows one? Suspect attribution failure before suspecting Windows. Look at what else is loaded, especially storage and security filter drivers, and corroborate across more dumps.

Are minidumps enough, or do I need the full dump? Minidumps resolve most consumer and workstation crashes, and their advantage — Windows keeps all of them — usually outweighs the extra detail in a single full dump. Escalate to a complete dump when you need the heap state around the fault.

Three Free Browser Tools Worth Bookmarking

DumpReader belongs to a small category of tools that solve one unglamorous problem completely — free, no account, no upsell. Two others earn a place in the same bookmark folder:

The practical pairing here: a MEMORY.DMP is hundreds of megabytes, over DumpReader's 32 MB ceiling, and too big for a free transfer tier. Pairchute moves it straight to whoever has WinDbg open, with no upload and no size cap.

One honest distinction across the three: DumpReader does upload — it parses the dump server-side and discards the bytes with the response, which is why the 32 MB limit exists. Pairchute and Parquetbay never upload at all; both work inside the browser tab, verifiable in the Network panel. Different jobs, different privacy models, and worth knowing which is which before you hand over a file that isn't yours.

The Bottom Line

A .dmp file is not unreadable, it is just unread — the barrier has always been tooling, not difficulty. A browser-based decoder removes that barrier for the common case, hands you the stop code, a confidence-rated lead, the stack and the driver list, and is honest about the fact that a lead is not proof.

Use it to triage. Corroborate across several dumps before you believe any single name. Test the RAM the moment the culprits start varying at random. And keep WinDbg for the cases where being wrong is expensive.

Analyse a Crash Dump — Free