Blue screen: find the cause in the dump

A blue screen is Windows pulling the emergency brake. Swapping the RAM at random afterwards is like replacing the train because the brake worked. This guide reads the evidence first and spends money last.

The short answer

How do you find the cause of a blue screen? Write down the stop code, make sure Windows saves a dump file, then open the newest dumps in WinDbg and run !analyze -v. Microsoft's own analysis of crashes puts about 70 percent on third-party driver code, 10 percent on hardware, 5 percent on Microsoft code, and 15 percent on cases where the memory was too damaged to tell [1]. So update or remove drivers first, test memory and storage next, and buy a part only when a test shows the defect.

How it works

1. What a stop code is. When Windows meets a condition that could harm the system or your data, it stops on purpose. Microsoft calls that a bug check, a stop error or a kernel error [1]. The screen shows a name such as PAGE_FAULT_IN_NONPAGED_AREA or MEMORY_MANAGEMENT and, if available, the module that was running [15]. Four parameters belong to every code. The name tells you the kind of failure, not the part that broke. For 0xD1, DRIVER_IRQL_NOT_LESS_OR_EQUAL, Microsoft says a kernel-mode driver touched pageable memory while the processor's interrupt level was too high, usually through a bad address [13]. A user program such as Notepad can trigger a crash, but it is rarely the root cause [1].
2. Write it down and find it in the logs. Photograph the screen. In Event Viewer, open Windows Logs and then System. Event ID 1001 from WER-SystemErrorReporting says the computer rebooted from a bug check and lists the code and the dump path. Event ID 41 from Kernel-Power says the system rebooted without a clean shutdown [8]. Event 41 carries the bug check code in decimal; Microsoft's example shows 159, which converts to 0x9F [7]. A dirty shutdown is also logged as Event ID 6008 [8]. If Event 41 shows a bug check code of zero or does not exist at all, Microsoft points to power: an unplugged desktop, a drained battery or an underpowered or faulty power supply [7].
3. Make sure dumps get written. A machine set to write no dump leaves no evidence. Open Advanced system settings, then Startup and Recovery, and under "Write debugging information" choose Automatic memory dump [1]. Small dumps land in %SystemRoot%\Minidump, the larger kinds in %SystemRoot%\MEMORY.DMP [1]. A small dump is tiny; Microsoft's pages give 256 KB [1] and 64 KB [11]. The dump is staged through the page file, and for a complete memory dump Microsoft requires an adequate page file on the boot volume [16]. Keep 10 to 15 percent of the system drive free [1][15]. Keep several dumps. One dump can mislead; the same pattern in three is a lead.
4. Find out when it started. Reliability Monitor draws a timeline of failures per day. Start it with perfmon /rel [9][10]. Compare the first red entry with driver installs, Windows updates and hardware changes. Event ID 19 from WindowsUpdateClient marks installed updates [8].
5. Undo the last change first. Before any debugger work, Microsoft's general list applies [1][6][15]. Remove hardware you added shortly before the first crash. Start in Safe Mode if Windows does not boot (it loads only the minimum of drivers [6]). Check Device Manager for devices with an exclamation mark. Install Windows updates and the newest BIOS or UEFI firmware. Roll back a recently updated driver, or use a restore point. Run a malware scan, for example with Microsoft Safety Scanner [1].
6. Open the dump in WinDbg. Microsoft's route is to copy the dump to another computer and install Debugging Tools for Windows from the Windows SDK [1]. Copy the files out of the Minidump folder first; you need administrator rights to read it. In WinDbg, set the symbols with .symfix, which points to Microsoft's public symbol server, then run .reload [5]. Symbols turn addresses into names; without them the analysis says little. Open the file with File, then Open Crash Dump (Ctrl+D) [2]. Run !analyze -v [2][3]. .bugcheck prints the code and its parameters, and lm lists the loaded modules [2].
7. Read the output. !analyze starts with the bug check name and a short text, then lists Arg1 to Arg4 with a description for each [4]. Further down, look at MODULE_NAME and IMAGE_NAME, the module the debugger blames, and at STACK_TEXT, the chain of calls [4]. Microsoft's own advice is to read STACK_TEXT for the DLL or service involved [1]. Your output may show more keys than the documentation's example. How does the debugger pick a name? It walks the stack from the top and blames the first frame whose owner it can determine [4]. That is a heuristic, not a verdict. Two examples from Microsoft show how different the fixes are. In one, the stack pointed to the Windows Firewall service, and resetting the firewall policies repaired it. In the other, a D1 crash sat in NDIS.sys, a Microsoft driver you cannot remove, and the fix was to disable the network device and retry the upgrade [1]. For 0xD1, the command dx KiBugCheckDriver prints the driver name Windows stored [13].
8. Why ntoskrnl.exe is rarely the culprit. Microsoft puts only about 5 percent of crashes on Microsoft code [1]. The kernel often appears because it detected the problem, not because it caused it. For some MEMORY_MANAGEMENT cases Microsoft says outright that the calling stack "might be either a victim or a culprit" [12]. Our assessment: if the dump names ntoskrnl.exe, treat the result as unattributed. Do not reinstall Windows because of that file name. Scan the stack for other modules, compare it with your other dumps, and move on to Driver Verifier.
9. Driver Verifier. The built-in tool puts drivers under strict checks, so a driver that corrupts memory crashes at the moment of the offense and the next dump names it [1]. Microsoft's warnings: it uses a lot of CPU and can slow the PC down, it can cause extra crashes and many dump files, you should not verify all drivers at once, and groups of 10 to 20 drivers are the guideline. Start with recently updated or suspicious drivers. If the PC no longer reaches the desktop, start in Safe Mode, where Verifier does not run [1]. Our advice: create a restore point first and turn Verifier off after you have the dumps. The same Microsoft page says elsewhere that about 75 percent of stop errors come from faulty drivers, while its main statistic says 70 percent [1]. Both figures say the same thing: drivers first.
10. Driver, memory, disk or power? Several dumps with the same code and the same third-party module point to that driver. Codes and modules that change from crash to crash fit hardware better, and Microsoft notes that hardware problems cause erratic, unpredictable behavior and are hard to diagnose [1]. The table below collects what Microsoft writes for common codes.
11. Test hardware only when the evidence points there. For memory, run Windows Memory Diagnostics (search for "Diagnose your computer's memory problems"). Afterwards, Event Viewer shows the result in the System log under MemoryDiagnostics-Results [6]. Our assessment: a clean pass is evidence, not proof. If the crashes continue, test one memory module at a time. For the file system, Microsoft names chkdsk /f /r [1] and SFC /scannow for system files [6]. For drives, PowerShell's Get-PhysicalDisk reports a HealthStatus of Healthy, Warning, Unhealthy or Unknown [18], and Get-PhysicalDisk | Get-StorageReliabilityCounter shows temperature, errors and wear [17]. Not every disk reports these values [19]. Microsoft's example says any drive that reports read or write failures should be considered at risk [19]. For SMART values in detail, see the SSD health guide under "Related pages". Also run the diagnostics of your PC maker [6].
12. When a part is really defective. Spend money only on a part with a repeatable test result: memory errors in the diagnostic, read or write errors in the drive counters, a WHEA error that stays after you switched off overclocking and checked cooling. Back up before you replace a drive. If nothing shows a defect, a new part is a guess, and guesses tend to cost twice. We name no shops in this guide.
13. If you need help. Collect the stop code and all four parameters, the newest dump files, the text of Event 1001, the list from lm t n [13] and what you changed before the first crash. Microsoft support also asks for a memory dump to speed up a case [16].

What Microsoft says about common stop codes

A homelab example

This is a generic walk-through for your own Windows PC, not a report on our systems. The numbers and names in the sample output are invented, and we did not run these commands.

Step one: list the unclean-shutdown events and copy the dumps to a folder you can read.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1001,6008} -MaxEvents 20 |
  Format-List TimeCreated, Id, ProviderName, Message
New-Item -ItemType Directory "$HOME\Desktop\dumps" -Force
Copy-Item C:\Windows\Minidump\*.dmp "$HOME\Desktop\dumps\"

Step two: in WinDbg, open one dump with Ctrl+D and run these commands one after the other.

.symfix C:\Symbols
.reload
!analyze -v
.bugcheck
lm t n

Imagine this excerpt from the output (invented values):

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arg1: 0000000000000010, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80123456789, address which referenced memory
MODULE_NAME: examplegfx
IMAGE_NAME:  examplegfx.sys

How you read it: the code is 0xD1, so a driver is involved [13]. The named image examplegfx.sys is a third-party file, which fits Microsoft's 70 percent [1]. Open the other two dumps. If they name the same file, update that driver or roll it back, run the PC for a week, and look at Reliability Monitor again. If the other dumps name different files and different codes, stop blaming the driver, run the memory diagnostic and the drive checks from step 11, and check Event 41 for power hints.

Checklist

• Photograph the blue screen and write down the stop code and its four parameters.
• Check that Startup and Recovery writes an Automatic memory dump and that the system drive has 10 to 15 percent free space.
• Copy the files from C:\Windows\Minidump to a folder you can read before you analyze them.
• Open Reliability Monitor with perfmon /rel and note the date of the first crash.
• Undo the last driver, update or hardware change before you start deeper tests.
• Set the symbols with .symfix, run !analyze -v on at least three dumps, and compare the module names.
• Treat ntoskrnl.exe as "unattributed" and look at the rest of the stack.
• Use Driver Verifier on a small group of suspicious drivers only, with a restore point in place.
• Run Windows Memory Diagnostics and chkdsk /f /r, and read the drive counters, before you suspect a part.
• Replace a part only when a repeatable test shows the defect, and back up first.

Related pages

SSD health: read SMART on Windows and Linux · Memory / RAM · Understanding NVMe SSDs · Documenting an exact hardware configuration · UPS – uninterruptible power supply · Stop code (bug check) · S.M.A.R.T.: drive health report