Common Windows BSOD stop codes explained: what they usually point toward

A stop code is a label for a class of kernel fault, not a component diagnosis. Windows defines thousands of them, and each corresponds to a specific internal check failing: an invalid memory access at the wrong privilege level, a process that must exist but is gone, a watchdog that timed out. When the check fails, the matching code is chosen, written to a crash dump, and shown on the screen.

This is why the same code can have many causes. IRQL_NOT_LESS_OR_EQUAL, for example, fires whenever kernel code touches memory at an invalid level — which a buggy driver, unstable RAM, or a corrupted structure can all trigger. The code tells you the shape of the fault; it doesn't tell you the source.

Keeping four ideas separate is where good diagnoses start, because mixing them is where they go wrong:

A stop code is evidence that points toward a likely category. It becomes a confirmed cause only after a diagnostic test agrees. That gap — between "points toward" and "confirmed" — is the entire job of troubleshooting, and it's why the sections below pair every code with the test that would actually confirm it.

The first, most important step is to capture the code while it's on screen: the stop code name, the hex bugcheck, and any QR code or parameter values. A phone photo works. If the machine restarts before you can, the code usually still exists in two places — the Event Viewer (System log, the BugCheck entry) and a minidump file under C:\Windows\Minidump.

Record the context too, because context often beats the code: what were you doing (gaming, waking from sleep, just booted, right after an update)? How often (once, or daily)? Under load or at idle? Two machines with the same stop code can have completely different causes depending on that context — a DPC_WATCHDOG_VIOLATION under heavy disk use points a different direction than one at idle.

When the code is on screen only briefly, don't guess it later — a wrong code sends the whole diagnosis off track. If you can't read it at all, the minidump is your fallback: how to read a Windows minidump walks through opening the dump and pulling out the bugcheck and the suspected module.

Every diagnosis, whatever the code, follows the same five stages: the system hits a fault, Windows records a stop code, the code points toward a cause category, you run the diagnostic that fits that category, and the result either confirms a fix or sends you to the next investigation. The difference between a fast fix and a long hunt is almost always running the right stage in the right order — not doing more of the wrong stage.

The category in the middle is the pivot. Get it wrong and every test after it is aimed at the wrong target — which is why the next section maps codes to categories before the reference dives into each one.

The table below maps the most common codes to the category they most often implicate and the first check that usually makes sense. Use it to orient, not to conclude — a code on a border (like PAGE_FAULT_IN_NONPAGED_AREA, which is both memory and storage) may need both checks.

The eight categories below each get a dedicated section. Pick the one that matches your code, or use the decision tool if you're not sure where to start.

If you'd rather have a guided route than a map, answer a few questions. This points you to the right category and the guides that cover it. It's a decision aid, not a diagnosis — it narrows where to look, and the links take you to the specific guide for the situation you describe.

Drivers run in the kernel, which means a single bad one can bring the whole machine down. A driver that references the wrong address, spins a routine forever, or writes past a buffer will trip one of the driver-associated codes: IRQL_NOT_LESS_OR_EQUAL, KMODE_EXCEPTION_NOT_HANDLED, DRIVER_IRQL_NOT_LESS_OR_EQUAL, DRIVER_OVERRAN_STACK_BUFFER, DPC_WATCHDOG_VIOLATION, and parts of SYSTEM_SERVICE_EXCEPTION and KERNEL_SECURITY_CHECK_FAILURE.

The key distinction: a code that "points to a driver" doesn't tell you which one. The minidump often names a module, but that module can be a victim of the fault rather than its cause. So the driver path is a sequence, not a single action: was a driver recently changed or updated? Roll that back first. If not, look at the minidump, update the named driver from its vendor, and re-test. That order — recent change before random module — saves the most time.

Just as important is what not to do. Don't run a third-party "driver updater" that pushes a bundle of drivers you didn't ask for — that's a common cause of new crashes, not a cure. Get drivers from the hardware vendor or Windows Update. And don't assume an update always helps; a driver update is very often the cause of a new recurring code, in which case the fix is to roll it back, not forward.

• Check for a recent driver change or Windows Update first.
• Read the minidump for a named module (a strong lead, not a verdict).
• Update or roll back that driver from the vendor, then validate over real use.

Faulty or unstable memory is the great masquerader. Because any data the system reads from RAM could be wrong, a marginal stick can produce a wide range of codes — MEMORY_MANAGEMENT, PAGE_FAULT_IN_NONPAGED_AREA, IRQL_NOT_LESS_OR_EQUAL, PFN_LIST_CORRUPT, even UNEXPECTED_KERNEL_MODE_TRAP. A memory-related code is therefore a hint to test memory, not a verdict that the RAM is dead.

The right approach is methodical. Windows Memory Diagnostic is the quick first pass; a longer, repeated test (such as MemTest86 run from a USB) catches more, because marginal cells often fail only after many passes or only under heat. If you have more than one stick, test them individually — an error that follows one specific stick localizes the fault. And check for a memory overclock (XMP/EXPO or an explicit frequency): a profile that's a little too aggressive is a very common source of "random" memory crashes, and dropping to JEDEC defaults is a fast, free test.

Interpret the results carefully in both directions. A clean quick test doesn't rule out marginal RAM — it may just not have stressed the failing cells. And a single reported error doesn't always mean a dead module; correlate it with the crash pattern (random at idle vs. under load) and, if possible, re-test before replacing hardware.

Storage problems show up as INACCESSIBLE_BOOT_DEVICE, DPC_WATCHDOG_VIOLATION, PAGE_FAULT_IN_NONPAGED_AREA, and NTFS-related codes. Two very different problems hide under "storage," and telling them apart matters: the logical layer (the filesystem and its metadata — repairable with a file-system check) and the physical layer (failing cells on an SSD or failing platters/heads on an HDD — not repairable, only replaceable). A health check (SMART data) tells you which layer you're dealing with before you choose a tool.

Two of these codes deserve a special note. DPC_WATCHDOG_VIOLATION is especially common with SSDs and their drivers or firmware — so "storage" here often means the NVMe/SATA driver or the SSD's firmware version, not a dying disk. INACCESSIBLE_BOOT_DEVICE is very often a storage driver, a failed update, or a boot-mode change (UEFI vs. legacy), not a dead drive — the machine can lose sight of its own boot partition for a purely software reason and find it again once the driver or setting is corrected.

The GPU and its driver have their own two codes: VIDEO_TDR_FAILURE and VIDEO_MEMORY_MANAGEMENT_INTERNAL. TDR stands for "Timeout Detection and Recovery" — it's Windows' mechanism for noticing that the GPU stopped responding for too long and resetting the graphics driver. A TDR is, in other words, the system catching the graphics stack in the act of stalling, which is why it's so useful a clue.

The order of likelihood matters here, because it changes what you do first. The most common cause is the graphics driver — a bad update, or a driver that can't handle a particular workload. Next come thermal problems and unstable overclocks (a GPU pushed past what its cooling or power can sustain). A genuinely failing GPU is real but comes later in the order. So the practical path is: update or roll back the GPU driver, check the temperature under load, undo any GPU overclock or undervolt, and only then start suspecting the hardware.

Workload correlation is your friend. Crashes during gaming, 3D, or video rendering point more strongly at the graphics stack; a VIDEO_TDR_FAILURE at an idle desktop with a known-stable driver may point elsewhere entirely (a driver conflict or a memory issue). Note what you were doing when it crashed and let that weight the diagnosis.

When the operating system's own files or configuration are damaged, you see codes like CRITICAL_PROCESS_DIED, KERNEL_SECURITY_CHECK_FAILURE, BAD_SYSTEM_CONFIG_INFO, SYSTEM_SERVICE_EXCEPTION, and SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. These are, loosely, "the system hurt itself" codes — the corruption is in Windows, not necessarily in a device driver.

The right tool is SFC and DISM, which repair protected system files and the underlying image. But be precise about what a successful scan actually means: it means the protected files now match the correct versions. It does not mean the original cause is gone. If the corruption keeps coming back after a clean repair, something is still causing it — a misbehaving driver, malware, or a failing disk silently writing bad data — and that's the thing to chase next.

BAD_SYSTEM_CONFIG_INFO is worth calling out separately. It's more about the registry and startup configuration than about loose files — commonly the result of a bad update or a failed driver install leaving a critical key broken. The fastest fix there is usually a System Restore to a known-good point rather than a file repair. And a caution: third-party "registry cleaners" don't fix this and can make it worse by removing keys Windows needs — avoid them.

Some crashes originate below the operating system, in the firmware. ACPI_BIOS_ERROR comes from ACPI — the power-management firmware interface — and, in part, CLOCK_WATCHDOG_TIMEOUT and WHEA_UNCORRECTABLE_ERROR can trace back to a firmware bug. These are the hardest codes to fix from inside Windows, because the fault isn't in Windows.

The usual lever is a BIOS/UEFI update from the motherboard or laptop vendor, or resetting firmware settings to defaults after a change. If you recently tuned a power setting and started getting ACPI_BIOS_ERROR, reverting that setting is the first thing to try. On older boards, this code can also reflect a firmware bug or a power-management conflict that a firmware update addresses.

Three codes are the "the hardware reported a real error" group: WHEA_UNCORRECTABLE_ERROR, MACHINE_CHECK_EXCEPTION, and CLOCK_WATCHDOG_TIMEOUT. WHEA — Windows Hardware Error Architecture — collects hardware error reports from the platform, and MACHINE_CHECK is the CPU itself reporting a hardware fault. When you see these, the machine is telling you something at the silicon level went wrong, which is a different register from a driver bug.

The single most useful next step is the Event Viewer, specifically the WHEA-Logger and System logs, because they usually record which component or address raised the error — turning a vague "hardware error" into something you can act on. A one-off WHEA under heavy load can be a marginal component pushing past its limits; recurring entries point to a component that's genuinely failing (RAM, CPU, GPU, or another). Read the specific entry before concluding anything.

Don't panic-replace parts. The sequence that holds up: read the specific hardware error, check temperatures (overheat can trigger these), undo any overclock, and test the most likely component — usually memory — before spending money. And if a serious hardware error is recurring, treat your data as at risk: back it up early, not after the component finally fails for good.

DRIVER_POWER_STATE_FAILURE is the signature code for crashes during sleep, resume, or shutdown. It means a driver failed to respond correctly to a power-state transition — the system asked it to go to a new power state and it didn't complete in time. It's one of the most common "my PC crashes when it wakes up" or "it bluescreens when I close the lid" codes, and the trigger is almost always a specific driver rather than a deep system or hardware fault.

The fix is usually the driver that failed the transition. The minidump tends to name it, and it's frequently a USB, network, or audio driver. Rolling back or updating that one driver, or adjusting the relevant power setting (for example, a device's PCIe power management or USB selective suspend), often resolves it completely. Because the crash is tied to a transition, it's also often tied to a specific device — if it always happens when a particular peripheral is present or when the system resumes, that's a strong pointer to that device's driver.

These are almost always software or driver problems, not hardware — so the "test the hardware" instinct is usually the wrong first move here. Target the named driver and the matching power setting first, and you'll typically find the cause faster than by going after memory or the disk.

All 22 common codes, each expandable. Use the category filter to narrow to an area, or the search box to jump straight to your code. Each entry follows the same shape — what it means, what it usually points toward, what it doesn't prove, what to check first — and links to the dedicated guide. Treat every entry as a starting point, not a verdict.

22 stop codes

No stop codes match that search. Try a shorter term or switch the category back to All.

These are the diagnostics the categories above point to. Run them from the matching path (system codes → SFC/DISM; memory codes → Memory Diagnostic; storage codes → disk health; thermal/hardware → the energy report). Each does a specific job, and none of them "fixes" a BSOD by itself — they produce the evidence the diagnosis needs.

A stop code is a map, not a destination. It narrows the search to a category; the diagnostic test confirms the cause. The single most common mistake is skipping that second step — replacing a part or reinstalling Windows on the strength of a code alone.

The workflow that holds up: record the code, pick the category, run the matching test, confirm the fix, and only then move to the next suspect. If you work through a code and the matching test comes back clean, trust that result and widen the search rather than repeating the same step.

From here, use the full reference above and the decision tool to pick your path, then follow the dedicated guide for your exact code. For the broader first-response process — including crash loops, Safe Mode, and how to keep the loop from coming back — the main blue screen guide is the natural next read.