How to read a Windows BSOD stop code and turn it into a troubleshooting clue

When Windows can't recover from a fault, it doesn't just stop — it records the nature of the fault and shows it to you as a stop code. The code is a symbolic name (something like IRQL_NOT_LESS_OR_EQUAL), and it corresponds to a numeric bugcheck code in hexadecimal (something like 0x0000000A). They're the same fact in two forms: a word and a number. Both describe what kind of error the kernel hit, and neither names the component that caused it.

That distinction is the whole game. A stop code is a category of failure, the way a symptom is a category of illness. "Fever" doesn't tell you whether you have the flu, an infection, or something else — it tells you where to start looking. Similarly, a memory-management stop code can come from a faulty stick of RAM, a driver that wrote to a bad address, or a corrupted system file. The code points you toward an area; a test is what confirms a cause. Holding onto that — clue, not verdict — keeps you from buying a part you don't need.

The other thing the screen gives you is the additional parameters (extra hex values after the bugcheck code) and, on modern Windows, a QR code that links to Microsoft's description of that specific stop. The parameters often carry an address or an object handle — noisy for a human, but sometimes they identify the module that was involved. We'll go through exactly how to use each of these in the sections below, and how much weight to give each one.

The single most useful habit in BSOD troubleshooting is boring: record the code before you do anything else. The blue screen is the only moment you can read it directly, and if the machine auto-restarts — which it often does by default — that information is off the screen. It's frequently recoverable later from the logs and dumps (we cover where, in a minute), but the on-screen version is the cleanest copy you'll ever get, so treat the first thirty seconds of a crash as the important ones.

When the screen appears, grab four things: the stop code (the name), the bugcheck code (the hex number), whether there's a QR code (scan it or note that it's there), and — as important — the context. What were you doing? Did it happen at boot, under load, after an update, after you plugged something in? Write all of it down. Context is half the diagnosis; the same stop code that appears after a driver update means something very different from the same stop code on a machine that's been fine for three years.

Why "before you change anything"? Because every fix you apply is also a variable you're introducing. If you reboot, run a repair, and swap a cable all in one sitting and the machine then works, you have no idea which of the three did it — and next time the crash returns you're starting from zero again. Recording first, then changing one thing and confirming it, is slower in the moment and the only approach that actually builds understanding of the machine. That discipline is what separates a fast fix from a long guess.

The table below covers the stop codes that come up most often, the area each one is usually worth pointing at, the evidence that helps, and a sensible first investigation. Read it as a map, not a diagnosis — the "often points toward" column is a place to start, and the same code can have more than one cause. Search by code name or description, or filter by the kind of component you suspect.

No stop codes match that search. Try a shorter keyword, or switch the area filter back to All.

Not seeing your code? The next section explains how to read an unfamiliar one, and the BSOD series has the broader code-by-code reference.

Answer a few questions about your machine and this will suggest where to start. It's deliberately a direction, not a diagnosis — it weighs the signals you give it and points you at the most reasonable next step. Nothing here can read your hardware; it's a structured way to avoid jumping to the wrong conclusion.

A modern blue screen usually shows three things worth reading. The stop code is the symbolic name and is the most human-friendly part — it's the label you'll search for. The bugcheck code (a hex number like 0x0000007E) is the numeric identity of the same error; if the screen is blurry or you only catch the number, that's still enough. And the parameters — a short list of hex values after the bugcheck code — carry details about the specific fault, often including a memory address or a reference to the code that was running when things went wrong.

Here's how much weight to give each. The stop code and bugcheck are reliable and stable: they'll match what the logs record later, so trust them. The parameters are less reliable for a human because their meaning depends on the specific bugcheck — for some codes parameter 1 is a memory address, for others it's a handle or a status code, and a raw hex value is not very actionable without knowing which. Don't fixate on decoding parameters by hand; that's what a crash-dump analysis tool is for (see the WinDbg section). What you can do is note that parameters were present, because their presence and values matter when you open the dump.

The QR code is the underrated field. It links to Microsoft's page for that exact stop, which names the code, describes the general cause, and sometimes lists the meaning of each parameter for that code. It's the fastest way to go from "I have a code" to "here's what this code means and what it's checking." If there's no QR (some older builds don't show one), the stop code name is still a good search term. The point of all of this is to convert the screen into a searchable, loggable fact — and to resist the temptation to treat that fact as the finished answer.

If the machine restarted before you could read the screen, don't panic — Windows keeps a record. The two fastest places are the Reliability Monitor and the System log in Event Viewer. Reliability Monitor is the friendlier of the two: it shows a timeline of system stability with the crash marked, and clicking the event reveals the stop code and the time. You can open it directly by running perfmon /rel from the Start menu or a terminal, or by navigating to Control Panel → System and Security → Action Center → View reliability history.

The Event Viewer is the more precise source. In the System log, a blue screen is recorded as a BugCheck event (source Kernel-General, Event ID 1001), and its description contains the stop code and the parameters. That's the same data the screen showed, so if you missed it, this is where you recover it. There's also an important related entry: Kernel-Power, Event ID 41, which logs an unexpected shutdown. Be careful with that one — a 41 means "the machine stopped without shutting down cleanly," which is true for a BSOD but also for a hard power cut or a thermal shutdown, so a 41 on its own isn't proof there was a blue screen. Pair it with a BugCheck event to be sure.

One practical note on why you should check these even when you did catch the screen: the logs give you the crash history, not just the last one. Seeing whether the same code is repeating, or whether different codes are appearing, changes the diagnosis a lot — a single code repeating points at a stable underlying cause, while a rotating set of codes can point at something less specific (unstable power, marginal hardware, or a deeper integrity problem).

Event Viewer is less about "finding the code" (the logs give you that) and more about building context around the crash. The crash itself is a single point; the useful evidence is what happened in the minutes before it. Open eventvwr.msc, go to Windows Logs → System, and sort by time so the crash is easy to find. Then read backwards from the BugCheck entry and look for warnings that line up in time: a disk warning, a driver service failure, a thermal or power event, a failed update install. Those nearby warnings are often the real story, with the BSOD as the climax.

Two entries deserve specific attention. The BugCheck (1001) entry is your confirmation and gives the stop code plus parameters — the raw material for a dump analysis. The Kernel-Power 41 entry confirms an unclean shutdown, as noted above, but only means "a BSOD" when it sits next to a BugCheck; on its own it just means the power went away. A third pattern to watch for is a run of disk errors (source disk or Ntfs) leading up to the crash — that's a strong pointer toward storage, and it's worth following even if the stop code doesn't scream "disk." The skill here is correlation: match the timestamps, and let the pattern, not a single line, steer you.

Keep two cautions in mind. First, Event Viewer is evidence, not a fix — it tells you where to look, it doesn't change anything, which is exactly what you want at this stage. Second, don't clear the log while you're investigating; the history is the value. If the crash is recent and you're about to reboot or run repairs, take a quick screenshot of the relevant entries first. That screenshot is part of your evidence kit and makes it far easier to reason about the crash later or to explain it to someone else.

When Windows crashes, it can write a crash dump — a snapshot of the system's state at the moment of failure. A minidump is the compact version, usually a few hundred kilobytes, and by default Windows writes one for each crash to C:\Windows\Minidump. These files are the difference between "I have a stop code" and "I can see which module was involved." If you have them, you have the most direct evidence available short of opening the case.

First, make sure you're actually getting dumps. If that folder is empty but you've been crashing, the dump type may be set to "None." You can change it without third-party tools: open System → Advanced system settings → the Startup and Failure section, and under Writing debugging information choose Automatic memory dump or Kernel memory dump. A kernel dump is a good balance — detailed enough for analysis, small enough to not fill the drive. (There's a command-line equivalent using bcdedit, but the System properties dialog is the safer, more visible way to make this change, so start there.)

What's in a minidump? The stop code and its parameters, the state of the kernel, the set of loaded modules, and — most usefully — the thread that was running when the fault happened, which usually names a module (a driver or system file). You don't need to read the file's raw bytes; that's what a tool is for. The human job is to collect the dumps (keep the ones that match your crashes) and to notice patterns across them — the same module named in three different dumps is a very different signal from a different module every time. That's exactly the step the next section automates.

WinDbg is Microsoft's own debugger and the standard tool for reading crash dumps; it's free and it's the same tool Microsoft support uses. You don't need to be a programmer to get value from it. The workflow is: open a minidump file in WinDbg, run the automatic analysis command, and read the top of the output. That single command does the heavy lifting — it re-derives the stop code, summarizes the likely cause, and (crucially) calls out the suspect module. For an intermediate user, that's usually enough to know whether a specific driver is implicated.

Read the output for three things. The BUGCHECK_CODE and BUGCHECK_STR confirm the stop you're looking at. The "Probably caused by" line and the MODULE_NAME/IMAGE_NAME fields name the module WinDbg thinks was involved — often a .sys driver file. And the surrounding text may point at a specific function or a memory address. This is where the minidump pays off: you go from "memory-management crash" to "the crash occurred while exampledriver.sys was running," which is a concrete, testable lead.

Now the important caveat, because it's where people go wrong: "probably caused by" is a hypothesis, not a verdict. A faulty driver can corrupt memory that a different component trips over later, so the module WinDbg names is sometimes a victim rather than the culprit. That's why the reliable move is to analyze several dumps, not one. If the same module appears as the suspect across multiple crashes, your confidence is high. If a different module shows up each time, the common thread is more likely to be the underlying condition (unstable memory, a failing drive, marginal power) rather than any single driver. Let the pattern across dumps make the call, and treat any single analysis as a strong lead rather than a finished answer.

Drivers are the software layer closest to the hardware, and because Windows trusts them with low-level access, a bad driver can bring the whole machine down. That makes drivers one of the most common causes of a new, recurring crash. The signature of a driver problem is usually temporal: the crashes started after a driver was installed or updated — a graphics driver, a network adapter, a storage controller, or a chipset package. If the timing lines up, a driver is worth checking before anything else, because it's also the easiest thing to roll back.

How to look. Device Manager (run devmgmt.msc) is the place to see what's installed and, importantly, when. Right-click a device → Properties → the Driver tab shows the driver date and version, and often a Roll Back Driver button if a previous version exists. If a crash started after a specific driver update, rolling that one driver back is a clean, low-risk test: do it, reboot, and see if the crashes stop. A minidump strengthens the case — if WinDbg names a vendor .sys file, you know exactly which device to look at. Correlate the dump's module with the device list and the change history, and you usually have your answer.

Two things to avoid. First, don't install third-party "driver updater" utilities to "fix" drivers — they frequently install the wrong driver and create new crashes; get drivers from the device manufacturer or from Windows Update instead. Second, don't roll back every driver at once — that's the "change many variables" mistake. Roll back the one driver whose timing matches the first crash, confirm, and only then consider the next. If a driver rollback fixes it, you've both solved the crash and identified the cause, which is the ideal outcome.

Memory problems are the classic "hard to pin down" cause, because unstable RAM can produce many different stop codes — MEMORY_MANAGEMENT, PAGE_FAULT_IN_NONPAGED_AREA, and others — rather than one signature code. So the tell is often the pattern: crashes that seem random, with no clear trigger, and with the dump pointing at different modules each time. If the other areas (recent changes, a specific driver) don't fit, memory is the area that earns a proper test. The goal of a memory test is to find instability, not to prove a stick is dead beyond all doubt.

Start with the built-in tool. Windows includes Windows Memory Diagnostic; run mdsched.exe and choose to restart and check for problems. It's a reasonable first pass, though it's not as thorough as a dedicated bootable memory tester, so a clean result there is encouraging but not a guarantee. The more revealing test is isolation: if the machine has more than one stick of RAM, test with them one at a time, in each slot. A crash that only happens with a particular stick (or only in a particular slot) has just told you exactly what to replace or reseat. Reseating the modules — power off, unplug, remove, click them back in firmly — also fixes the surprisingly common "loose contact" problem.

One more angle specific to modern systems: if you've enabled a memory profile (XMP or EXPO) or any memory overclock in the BIOS, the RAM may be running faster than it's stable at. Resetting to the default (JEDEC) speed and retesting is a fast way to find out — if the crashes stop at stock speed, the profile was too aggressive for that hardware, and you can either lower it or leave it at defaults. Interpret any test result with care: a single reported error doesn't automatically mean a module must be replaced, and a clean quick test doesn't automatically clear it either. Weigh the test against the crash pattern, and prefer the isolation result (one bad stick/slot) over a single ambiguous number.

Storage-related crashes tend to announce themselves in a slightly different way: they often happen at boot, they can be preceded by a slow or freezing machine, and the stop code may name a file system or a disk (NTFS, RDR, a disk-related code). The underlying issue can be one of two very different things, and it matters which: file-system corruption (the data on the disk got scrambled, often after a bad shutdown) is usually fixable, whereas a physically failing drive is a replace-it-now situation. The first job is to tell those apart, and the first rule is to back up important data before you run anything aggressive.

Check the drive's health first, because it's the one that changes your urgency. A quick way is to ask Windows for each disk's health status in PowerShell with Get-PhysicalDisk; a status of "Healthy" is reassuring, while "Degraded" or "Pred Fail" is a strong signal the media itself is failing and that replacement (and a backup) should come before any repair. You can also look for disk warnings in Event Viewer leading up to the crash — a run of disk or NTFS errors before a BSOD is a meaningful pattern on its own.

For the file-system side, Windows has a disk-check utility. Running a scan is a reasonable diagnostic; understand that a full repair (/f) changes things on the volume and may take a while, and that it can't fix a physically failing drive — it can only repair logical file-system errors. So the sensible order is: check health, back up, then scan. If the drive reports healthy and a scan finds and fixes file-system errors, that may well be the cause, and the crash may not return. If the drive is degraded, or the errors keep coming back, treat the drive as the failing component: back up, replace, and restore — don't keep a failing drive as your only copy of anything important.

"It started after an update" is the most common and the most actionable BSOD story, because the cause and the fix are the same event. The discipline here is to build a timeline rather than guess: when exactly did the first crash happen, and what got installed or updated in the days before? Check the Windows Update history, note any driver updates (graphics, network, chipset), and line them up against the first crash in Event Viewer. When the first crash sits shortly after a specific update, that update is your prime suspect — and, crucially, it's the one thing you should undo first, because it's the highest-probability fix and the easiest to reverse.

Undoing is straightforward and reversible. For a Windows update, go to Settings → Windows Update → Update history → Uninstall updates and remove the suspect update, then reboot. For a driver, use the Roll Back Driver option in Device Manager (Driver tab) for that specific device. The key is to do one of these, confirm over a bit of real use, and only then move to the next if the crash returns. This is the "one variable at a time" principle paying off: if the crashes stop after removing one update, you've fixed the crash and proven the cause, which tells you what to watch for next time that component updates again.

A word on not assuming the update is guilty just because it's the most recent thing. Sometimes the update is a red herring and the real cause is something that changed at the same time (a driver that shipped with it, a new app, a BIOS update). The timeline plus a minidump resolves the ambiguity: if the dump points at a module that wasn't touched by the update, the update may be innocent. So the update is your first thing to test, not your only thing to consider — test it, and let the evidence confirm or redirect you.

A crash that began right after you added hardware (a GPU, a drive, a stick of RAM, a card) is usually about that hardware — either the component itself, its driver, or how it interacts with the rest of the system. The cleanest diagnostic is isolation: get the machine back to the state it was in before the change and confirm it's stable, then reintroduce the change deliberately. If the machine is stable without the new part and crashes with it, you've isolated the cause to the new component or its setup. It's a bit of work, but it's the difference between a confident answer and months of guessing.

When you do reintroduce it, do it as a test, not a permanent install. Install the new part, install the manufacturer's driver (not a generic "updater"), and stress it a little to see if the crash reproduces. Pay attention to when it crashes: under load points at power delivery or thermals for that component; at a specific moment points at a driver or a firmware handshake; randomly could point at the part being marginal or incompatible. Also check the obvious physical things that cause exactly this symptom — a card not fully seated, a power connector loose, or a BIOS setting (like a memory profile or a power plan) that the new part doesn't like. A lot of "new hardware crash" problems are a loose connector or a BIOS default that needs a nudge, not a dead part.

Two cautions. First, be careful with anything involving opening the machine and touching components — power off and unplug first, and if you're not comfortable, that's a perfectly reasonable reason to get hands-on help; nothing in this guide requires you to do risky electrical work to make progress. Second, if the new part is RAM, remember it shares the diagnosis with the memory section — a marginal new stick can destabilize the whole memory subsystem, so test it in isolation like any other module. The goal in all of this is the same: find the one thing the change introduced, prove it's the cause, and then decide whether to fix the setup or return the part.

Everything above assumes you can get to a desktop to run tools. A crash loop — where Windows restarts into the blue screen again and again, often before you reach the login screen — changes the rules, because the fault is in something that loads on every boot and the normal desktop is off the table. The move is to work from a lower-level environment: the Windows Recovery Environment (WinRE) or Safe Mode. From there you can remove or roll back the trigger without the failing component loading. The most common triggers in a loop are a bad driver, a bad Windows update, or a failed install — all of them reversible from recovery.

The route, in order: force the machine into recovery (interrupt the startup a few times, or hold the power button to force it off and back on repeatedly), choose Troubleshoot → Advanced options → Startup Settings, and restart into Safe Mode (or Safe Mode with Networking if you need to download a driver). Safe Mode loads only the minimum, so if the machine is stable there, the trigger is a third-party driver or app — and you can now roll it back or uninstall it with the tools from the driver and update sections. If you can't get to Safe Mode at all, Advanced options also offers Startup Repair and Uninstall recent updates directly, and System Restore to jump back to a point before the loop began.

Safe Mode is also a diagnostic, not just a workaround. If even Safe Mode crashes, that tells you the cause is lower-level than a normal driver or app — point it at system files, storage, or hardware, and head toward the dump and storage sections rather than keep poking at drivers. And remember to grab evidence before you reboot out of recovery: if there are minidumps, copy them out first. The full step-by-step for reaching and using these recovery options lives in the BSOD crash-loop guide; this section is about how the loop fits into reading the code — it's the point where "I can't even get to the desktop" becomes "I'll work from Safe Mode and roll back the trigger."

A lot of BSOD trouble is self-inflicted, and it comes from a small set of repeatable mistakes. The biggest is treat the stop code as the diagnosis — buying the part the code "sounds like" it names, before any test confirms it. The code is a clue about an area, not a component with a serial number. Second is the "change everything at once" error: rebooting, running three repair tools, and swapping a cable in one sitting. When the machine then works, you've learned nothing, and when it doesn't, you've added variables you can't untangle. Change one thing, confirm it, then move on.

Equally common and equally costly is destroying the evidence. Clearing the minidump folder, wiping Event Viewer, or reinstalling Windows all throw away the very data that would name the cause — and reinstalling is the one you can't easily undo. A reinstall fixes the operating system, but it does nothing about a bad driver, unstable memory, or a failing drive, so it won't fix those causes and it erases your logs in the process. Save it for last. Related to that, avoid the "driver fixer" utilities — third-party updaters that promise to fix your drivers often install the wrong ones and create fresh crashes; get drivers from the manufacturer or Windows Update.

Finally, a couple of physical-behaviour cautions. Don't repeatedly force-restart the machine as a casual fix — a hard reset now and then to reach recovery is fine, but constant power cycling stresses components and can, on its own, cause the unclean-shutdown (Kernel-Power 41) events that muddy your diagnosis. And don't reach for risky registry edits on a hunch; unless you have a specific, well-understood reason, editing the registry to "fix" a BSOD is more likely to make recovery harder. None of this is about being timid — it's about keeping the machine in a state where the evidence is intact and each step you take actually teaches you something.

The difference between a person who solves a BSOD in an afternoon and one who's guessing for a month is usually records. Crash investigations live and die by evidence, and the evidence is perishable — it gets overwritten, cleared, or rebooted away. So treat the first session after a crash as an evidence-collection session, and build a small kit you can refer back to. It doesn't need to be formal; a folder and a note are enough, but it should be consistent.

What goes in the kit: the stop code and parameters (from the screen or the BugCheck event), a copy of the matching minidump(s) (from C:\Windows\Minidump), a screenshot of the relevant Event Viewer entries around the crash time, the change timeline (what was updated or installed before the first crash), and any test results you run (memory test, disk health, the WinDbg "probably caused by" line). The reason to bother is twofold. Internally, it lets you reason across multiple crashes instead of chasing each one fresh — the pattern across the kit is where the real diagnosis lives. And externally, if you do end up asking for help, a kit like this turns "it keeps blue screening" into a precise, answerable problem, which gets you a far faster and better answer.

Pulled together, the process is a sequence where each step produces the evidence the next one needs. The order matters, and the reason is the same one this whole tutorial keeps coming back to: you want every change to be testable. If you skip ahead — reformatting before testing memory, or swapping a part before reading a dump — you lose the ability to tell which step actually did the job. So work top to bottom, and resist the pull to jump to the dramatic fix.

1. Record the stop code and parameters while the screen is up (or recover them from the logs).
2. Record when the crash happened and what you were doing.
3. Identify what changed recently — updates, drivers, apps, hardware, BIOS.
4. Determine whether Windows can boot normally; if not, plan to work from Safe Mode / recovery.
5. Check Event Viewer / Reliability Monitor for the crash and the context around it.
6. Examine any minidump to see if a specific module is implicated.
7. Investigate drivers if the timing or the dump points that way.
8. Investigate memory if the pattern is random or the code is memory-related.
9. Investigate storage / system files if boot-time or disk codes are involved.
10. Consider recent updates or hardware changes and undo the most likely one.
11. Apply the least invasive fix that matches the isolated cause.
12. Test whether the crash returns over real use — the same code staying gone is the confirmation.
13. Escalate to deeper dump analysis only if the above doesn't hold.

The checklist below captures that sequence as tickable items; your progress is saved in this browser, so you can work through it across several sessions.

This guide is the reading half of the BSOD series. Pair it with the pillar for the wider workflow, or continue within this page from the angle that fits your machine.

The takeaway to carry out of this tutorial is short: a stop code is a clue, and the clue is only as good as the evidence you collect around it. Read the code, record the context, check what changed, and let Event Viewer and a minidump tell you where to point — then change one thing and confirm it. Do that and most blue screens go from "scary and random" to "understood and fixed." When they don't, you'll have an evidence kit that makes the next step — deeper dump analysis, or a hardware test — a clear one instead of a guess.