Reading a Windows BSOD Minidump to Find the Actual Cause

A Blue Screen of Death shows a stop code and restarts before you can read anything useful — but Windows almost always writes a minidump to disk first, containing exactly the information needed to find the actual cause, if you know how to read it.

Step 1: confirm dumps are being saved

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl"

By default, Windows saves a minidump to C:\Windows\Minidump\ on every BSOD. Confirm the folder actually has recent files:

Get-ChildItem C:\Windows\Minidump\ | Sort-Object LastWriteTime -Descending

Step 2: get the stop code and immediate context

WinDbg (available via the Microsoft Store, or as part of the Windows SDK) is the standard tool for actually analyzing a dump. Open the most recent .dmp file and run the automated analysis command:

!analyze -v

This single command does most of the work — it identifies the bug check code (the specific stop code, like 0x0000007E or DRIVER_IRQL_NOT_LESS_OR_EQUAL), and critically, attempts to identify the specific driver or module whose code was executing when the crash occurred.

Step 3: identify the actual culprit driver

The !analyze -v output includes a line like:

MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
FAILURE_BUCKET_ID: AV_nvlddmkm!unknown_function

A third-party driver named explicitly here (a GPU driver, a storage controller driver, security/antivirus software) is almost always the actual cause — Windows’ own core drivers are far less frequently implicated than third-party ones, since third-party code doesn’t go through the same internal review as Microsoft’s in-box drivers.

Step 4: match the stop code to a general cause category

A few stop codes are common enough to be worth recognizing directly: IRQL_NOT_LESS_OR_EQUAL and DRIVER_IRQL_NOT_LESS_OR_EQUAL almost always point to a driver bug (accessing memory at the wrong interrupt priority level); MEMORY_MANAGEMENT and PAGE_FAULT_IN_NONPAGED_AREA can be either a driver bug or genuinely failing RAM; CRITICAL_PROCESS_DIED means an essential system process crashed, often from third-party software interfering with it directly.

Step 5: update or remove the implicated driver

Once a specific driver is identified, check the vendor’s site for an updated version — GPU and storage controller vendors ship driver updates specifically to fix crash reports like this fairly often. If no update is available and the crashes are frequent, temporarily rolling back to a previous known-good driver version, or removing third-party security software one at a time, isolates the cause faster than reinstalling Windows outright.

Get-WindowsDriver -Online | Where-Object DriverProviderName -notlike "Microsoft*"

Step 6: rule out hardware if no consistent driver shows up

If !analyze -v implicates different, unrelated modules across multiple crash dumps with no consistent pattern, this points toward failing hardware (RAM in particular) rather than a single driver bug — Windows Memory Diagnostic (mdsched.exe) or a longer offline memory test is the appropriate next step rather than continuing to chase driver updates.

Why reading the actual dump beats guessing

The stop code alone (IRQL_NOT_LESS_OR_EQUAL) tells you almost nothing actionable on its own — dozens of unrelated bugs can produce the same stop code. The !analyze -v output’s identification of the specific implicated module is what turns “Windows crashed” into “this specific third-party driver crashed,” which is the difference between guessing at fixes and actually resolving the problem.