Reading a Memory Dump: From Crash to Named Driver

A blue screen is a crash the system chose rather than a crash that happened to it. Before stopping, Windows writes what it knows to disk. That file is the only account of what went wrong, and every other approach to diagnosing a bugcheck is guessing around it.

Confirm Dumps Are Being Written

Before waiting for another crash, make sure the next one will leave evidence.

The startup and recovery settings hold the dump type and the destination. A machine set to write no dump crashes and leaves nothing. This is a common default on some configurations and it is the first thing to change.

Two other conditions have to hold. The page file needs to be large enough and on a volume the dump can be written to, because the dump is staged through it. And there needs to be free space at the destination.

A small memory dump is the right default. It is compact, one file is kept per crash rather than being overwritten, and it contains enough for driver-level analysis. Kernel dumps hold far more and are worth configuring when small dumps are not enough and the crash can be reproduced.

Where They Are

Small dumps collect in a Minidump folder inside the Windows directory, named by date and sequence. Having several is useful: a driver that appears in every dump is a much stronger lead than one that appears in a single dump.

A kernel or complete dump is written as one file in the Windows directory and replaced by each new crash.

Opening One

Microsoft publishes debugging tools for Windows, available as part of the SDK and also through the Microsoft Store as a standalone debugger. Install from Microsoft rather than from a general search result.

Configure the symbol path to point at Microsoft’s public symbol server before doing anything else. Symbols translate addresses into function and module names, and without them the analysis produces very little. The debugger downloads what it needs on demand and caches it locally.

Open the dump file and run the automated analysis command. It reports the bugcheck code, its parameters, the process that was running, and its best attempt at attributing the fault to a module.

Reading the Output

Four things are worth extracting.

The bugcheck code names the category of failure. It is what appears on the blue screen, and it narrows the possibilities. See reading a blue screen for interpreting the common ones.

The parameters carry specifics, and their meaning depends on the code. For some bugchecks a parameter is an address, for others it is a status value that identifies the failure precisely.

The probable cause module is the automated attribution. It is a lead.

The call stack shows the sequence of calls that led to the fault, which is where the attribution came from. Reading it is what lets you judge whether the named module was the one that failed or the one that noticed.

Suspect, Not Verdict

The attribution deserves scepticism, for a specific reason.

A driver that writes outside the memory it owns damages something belonging to another component. The damage is discovered later, when that other component uses what was corrupted. The crash then occurs in the victim, and the dump names the victim.

This is why a Windows system file is often named as the probable cause. The correct reading is usually not that Windows is faulty but that something corrupted state it relied on.

Several dumps naming different modules, with one third-party driver appearing across them, is the pattern that identifies the real culprit.

When the Dump Points Nowhere

Crashes that name a different module each time, with no common thread, usually mean hardware rather than software. Whatever happened to occupy the damaged region is what fails, so the module varies.

Run the built-in memory diagnostic. A single reported error is enough to treat memory as the cause, and it eliminates a large category cheaply.

Storage is the other candidate, and the event log is the place it shows: disk timeouts and controller resets logged in the minutes before a crash change the picture entirely. Reading the event log covers filtering it.

Driver Verifier

Where a driver is suspected but no dump names it, Driver Verifier applies additional checks to selected drivers so that a misbehaving one faults immediately rather than causing damage that surfaces later.

It works by causing crashes. A machine with a badly behaved driver can become unable to boot normally while Verifier is enabled, and recovering means disabling it from Safe Mode. Know how to reach Safe Mode before turning it on. Enable it for third-party drivers only rather than for everything, and turn it off once the answer is found.

The dumps it produces are far more direct, because the fault is caught at the point of the violation rather than at the point of the consequence.

What People Get Wrong About This

The first mistake is waiting for a crash on a machine configured to write no dump.

The second is acting on the probable cause line without reading the stack or comparing several dumps. Replacing a driver named once, in one dump, is a coin flip.

A third is skipping symbol configuration and concluding the dump is unreadable. Without symbols it nearly is.

A fourth is enabling Driver Verifier without a route back. It is designed to crash the machine.

And the last is treating a dump as the whole picture. It records the moment of the fault. The event log records the minutes before, and that context is frequently where the actual cause is visible.