Windows BSOD Stop Codes: Full List and Fixes

Many Windows BSOD stop codes map to a small set of failure areas: driver, memory, storage, system file, firmware or BIOS, and hardware. I start with the code family, then run the fastest safe test for that area before changing anything else. I have seen rushed guesswork turn a recoverable crash into data loss, longer downtime, or a repeating boot loop.

A Blue Screen of Death is a Windows kernel halt that forces a restart. On Windows 10 and Windows 11, the stop screen may be blue or black, and Windows may show a brief message that the device ran into a problem and needs to restart.

A Windows stop code, also called a bug check code, can appear as hexadecimal text beginning with 0x, descriptive text such as PAGE_FAULT_IN_NONPAGED_AREA or MEMORY_MANAGEMENT, or both. Microsoft’s bug check reference says stop-code values begin with 0x in hexadecimal, which helps identify the failure family rather than the exact bad file or component. Microsoft Learn

That distinction matters. IRQL_NOT_LESS_OR_EQUAL can come from a bad driver, unstable RAM, or a device that corrupts memory through DMA. DPC_WATCHDOG_VIOLATION can reflect a storage controller stall, SSD firmware trouble, or a driver hanging during power transitions. I treat the code as a map, not a verdict.

How do I find the exact stop code after a crash?

Capture the exact stop code from the stop screen if possible, then confirm it after reboot in Reliability Monitor, Event Viewer, and the memory dump file. For recurring crashes, also record any named driver or module, system uptime before the crash, and what changed immediately before the problem started.

What to capture from the stop screen before reboot

Write down the descriptive text and any hexadecimal code. Examples include IRQL_NOT_LESS_OR_EQUAL with 0x0000000A, MEMORY_MANAGEMENT with 0x0000001A, SYSTEM_SERVICE_EXCEPTION with 0x0000003B, CRITICAL_PROCESS_DIED with 0x000000EF, and DPC_WATCHDOG_VIOLATION with 0x00000133. Those examples align with Microsoft’s bug check documentation. (dell.com) Microsoft Learn

If the screen names a file or module, record it exactly. Names such as nvlddmkm.sys, stornvme.sys, or ntfs.sys are useful clues, but they still need context. A named Microsoft file can be the victim of corruption rather than the true cause.

Where to check after Windows restarts

Reliability Monitor is often the fastest history view because it shows when crashes began and what else changed that day. Event Viewer is useful too, but it rarely settles kernel-crash diagnosis by itself. I use it to line up crash time, restart time, and nearby driver or disk warnings.

Check whether the crash started after a new driver, feature update, BIOS change, storage utility, VPN app, endpoint security tool, or newly attached hardware. Microsoft support guidance specifically recommends removing hardware added before the error when timing points that way. Microsoft Support

Where dump files live and what matters in them

Dump files contain memory information from the moment of the stop code. For recurring BSODs, a kernel-mode dump is usually the best middle ground because it keeps the most relevant kernel memory without the size of a full memory image. Microsoft Learn

Common dump locations include the main memory dump file and the Minidump folder. The exact path matters less than confirming that a dump was actually written. If repeated crashes produce no dump, that also becomes part of the diagnosis because it can point to storage, paging, or shutdown timing issues.

Capture-before-repair checklist

Exact stop code text and any 0x value.
Any named module or driver file shown on screen or in analysis.
Whether the crash happens during boot, sign-in, idle time, gaming, backup, sleep, resume, or heavy disk activity.
Approximate uptime before the crash.
Recent changes: drivers, updates, hardware, utilities, BIOS settings, security software.
Dump file location and whether a new dump appears after each crash.

According to Bug Check Code Reference – Windows drivers — The Windows bug check reference says stop-code values begin with 0x in hexadecimal. (source)

What should I try in the first 10 minutes?

Start with the least risky changes: boot Safe Mode if Windows keeps crashing, undo the newest hardware or driver change, check Device Manager for warning icons, install pending Windows updates, and confirm free disk space. If crashes began right after a known change, System Restore is often the fastest safe rollback. If you need a crash-log workflow, jump to our Event Viewer crash guide.

Use Safe Mode when normal boot is unstable

Safe Mode is the basic recovery path when Windows crashes before sign-in or soon after the desktop appears. I use it to strip startup down to core Windows drivers and services. If the system becomes stable there, the problem usually needs the third-party driver, filter, or startup stack to trigger.

If the system is stable only in Safe Mode, the odds shift toward driver, startup software, filter driver, or security stack issues rather than outright CPU failure.

Undo the last change first

Remove newly added hardware. Roll back the latest device driver if the issue started after an update. Uninstall tuning tools, storage filter software, RGB utilities, or third-party antivirus if the timing lines up. I change one variable at a time, then retest, because that keeps the trail clean.

Check Device Manager, Windows Update, and free space

Open Device Manager and look for the yellow triangle or down-arrow icons beside a device, then match that device class to the BSOD timing. I check Display adapters, Storage controllers, Network adapters, and System devices first, then compare the driver date and version against when the crashes began.

Install current Windows updates when the system has fallen behind or the issue follows a known support update path. I start at Settings > Windows Update, install the pending cumulative update, reboot, then check Optional updates for a matching driver only if the crash clearly lines up with that device class.

Check free space on the system drive. Microsoft recommends keeping 10% to 15% free space available because low free space can worsen paging problems, update failures, and dump creation issues. (Microsoft Support)

When System Restore is the fastest safe rollback

If the system was stable until a recent driver, update, or utility install, System Restore is often safer than making several smaller guesses. It is most useful when crashes began inside a short, obvious change window and Safe Mode still works well enough to launch recovery.

BSOD triage matrix: stop-code families, fastest next test, and escalation

BSOD triage matrix labels: use the code family first, run the single fastest safe test in that row, then escalate only if the same pattern repeats. The last column is the short escalation trigger, not a full repair list.

Failure domain	Common stop codes	Fastest next test in the first 10 minutes	What the pattern usually suggests	When to escalate to dump analysis
Memory	MEMORY_MANAGEMENT, PFN_LIST_CORRUPT, PAGE_FAULT_IN_NONPAGED_AREA	Remove recent RAM changes, return memory settings to default, test Safe Mode stability, check for driver timing	RAM fault, memory corruption from a driver, paging trouble, overclock instability	Same code repeats, crashes under mixed workloads, or different apps fail with similar memory symptoms
Driver	IRQL_NOT_LESS_OR_EQUAL, SYSTEM_SERVICE_EXCEPTION, KMODE_EXCEPTION_NOT_HANDLED, DRIVER_POWER_STATE_FAILURE	Check Device Manager, roll back recent drivers, remove new devices, test sleep and resume behavior	Bad or mismatched driver, filter driver conflict, power-state transition failure	Module name repeats, crash follows one device action, or Safe Mode stops the crashes
Storage	INACCESSIBLE_BOOT_DEVICE, NTFS_FILE_SYSTEM, DPC_WATCHDOG_VIOLATION	Check whether BIOS still sees the drive, remove storage tools, confirm free space, review recent storage driver changes	Controller driver issue, file system damage, SSD stall, boot path break	Boot loops continue, disk warnings appear, or the same storage stack module is named in dumps
Boot and system file	CRITICAL_PROCESS_DIED, INACCESSIBLE_BOOT_DEVICE	Try Safe Mode or recovery options, undo recent updates, use System Restore if timing is clear	Corrupt system files, failed update, broken boot-start driver, storage path issue	System cannot reach desktop, repair loops repeat, or rollback attempts fail
Hardware and firmware	WHEA_UNCORRECTABLE_ERROR	Return BIOS settings to default, remove new hardware, check whether crashes occur under load or heat	CPU, motherboard, power delivery, PCIe device, firmware instability	Repeated load-related crashes, event logs show hardware error records, or changes in drivers do nothing
Security and virtualization	SECURE_KERNEL_ERROR	Undo recent security software, virtualization, or firmware setting changes; update Windows first	Virtualization stack issue, secure kernel conflict, low-level security driver failure	Code repeats after clean boot steps or appears right after platform security changes

In practice, the first-test column is where I decide whether the case is still basic recovery or already worthy of dump analysis. A repeated family with the same trigger earns escalation faster than a one-off crash after a recent update.

Which stop codes usually point to memory, storage, driver, or hardware faults?

Memory codes usually involve corruption across apps or random crashes, storage codes cluster around boot or heavy disk activity, driver codes often follow updates or sleep and resume, and hardware codes tend to repeat under load. The family narrows the domain; timing and repeatability narrow the real cause.

Memory-linked patterns

MEMORY_MANAGEMENT and PFN_LIST_CORRUPT are strong memory-family signals. PAGE_FAULT_IN_NONPAGED_AREA sits between memory and driver diagnosis because it can mean bad RAM, a driver touching invalid memory, or corrupted data arriving from storage.

Repeated memory-family crashes across unrelated apps suggest a lower-level fault. A crash that starts right after a GPU, VPN, storage, or antivirus driver update leans back toward kernel-space software corruption instead.

Storage and boot patterns

INACCESSIBLE_BOOT_DEVICE usually means Windows lost access to the boot volume during startup. That can follow controller-mode changes, broken storage drivers, failed updates, or a drive beginning to drop offline under load.

NTFS_FILE_SYSTEM points toward file system trouble or the storage path beneath it. DPC_WATCHDOG_VIOLATION is often treated as a generic driver bug, but I regularly see it line up with storage stalls, NVMe controller issues, or resume-from-sleep failures.

Driver-led patterns

IRQL_NOT_LESS_OR_EQUAL, SYSTEM_SERVICE_EXCEPTION, KMODE_EXCEPTION_NOT_HANDLED, and DRIVER_POWER_STATE_FAILURE often trace back to drivers. The strongest clue is timing: login, USB attachment, Wi-Fi use, sleeping, resuming, docking, gaming, or updating one device class.

Microsoft recommends using Device Manager as part of troubleshooting, especially when a device shows warning indicators or the crash follows a driver change. That makes rollback, disable, or uninstall the cleanest next test. Microsoft Support

Hardware and firmware signals

WHEA_UNCORRECTABLE_ERROR is the stop code that most often shifts the diagnosis toward hardware or firmware. Repeated crashes under gaming, video encoding, stress, or wake events raise suspicion around CPU stability, firmware, memory training, PCIe devices, or power delivery.

How do I fix the most common recurring BSOD stop codes?

Fixes work best when matched to the code family. Start with the narrowest safe test: driver rollback for IRQL and power-state codes, default memory settings and RAM checks for memory codes, boot-path repair for storage codes, and firmware or hardware checks for WHEA. Repeated identical crashes deserve dumps, not guesswork.

IRQL_NOT_LESS_OR_EQUAL on Windows 11

The bug check reference includes code 0x0000000A for IRQL_NOT_LESS_OR_EQUAL. On Windows 11, I start with recent chipset, GPU, network, VPN, storage, and endpoint security drivers. If the crash follows sleep or resume, power-management drivers move higher on the list. (Microsoft Learn)

Then test the memory angle. If the system also shows occasional app corruption, install failures, or different stop codes around memory access, check RAM stability and any BIOS memory tuning. The screen style may differ on Windows 11, but the diagnosis still depends on code, timing, and repeatability.

MEMORY_MANAGEMENT and PFN_LIST_CORRUPT

The bug check reference includes code 0x0000001A for MEMORY_MANAGEMENT. Start by removing recent memory changes and returning RAM settings to default. If new memory was added, test without it. If no hardware changed, suspect a driver that corrupts memory before blaming the DIMMs alone.

Also check storage health and system file condition if these crashes began after hard shutdowns or disk warnings. Memory-family stop codes can be the visible result of bad reads coming from storage.

PAGE_FAULT_IN_NONPAGED_AREA, SYSTEM_SERVICE_EXCEPTION, and KMODE_EXCEPTION_NOT_HANDLED

PAGE_FAULT_IN_NONPAGED_AREA often sits on the border between memory and driver diagnosis. SYSTEM_SERVICE_EXCEPTION, with code 0x0000003B, and KMODE_EXCEPTION_NOT_HANDLED point more strongly toward a bad driver or kernel-mode software conflict. Microsoft Learn

Safe Mode is useful here. If the system is stable in Safe Mode but fails in normal boot, review newly installed drivers, low-level utilities, and security products. If dump analysis names the same third-party module more than once, that repetition matters.

INACCESSIBLE_BOOT_DEVICE, CRITICAL_PROCESS_DIED, DPC_WATCHDOG_VIOLATION, and WHEA_UNCORRECTABLE_ERROR

CRITICAL_PROCESS_DIED appears with stop code 0x000000EF. Treat it as a boot and system-file problem first, especially after update trouble, failed rollbacks, or disk corruption. If Safe Mode works, use that opening to remove the trigger or run recovery steps.

DPC_WATCHDOG_VIOLATION appears with stop code 0x00000133. Check storage drivers, SSD tools, chipset packages, and sleep-resume timing. If the crash only happens after idle or resume, the power path matters as much as the disk path.

WHEA_UNCORRECTABLE_ERROR deserves a cleaner hardware and firmware workflow: remove new hardware, return firmware settings to default, check whether the crash happens under load, and stop changing drivers at random if the pattern stays identical.

Fixing CRITICAL_PROCESS_DIED by boot state

The CRITICAL_PROCESS_DIED crash pattern guide sorts this Windows 11 stop code by boot state: desktop access, Safe Mode only, automatic repair loop, or a black screen. Categorizing the failure first prevents changing multiple settings at once and directs you to the correct diagnostic step immediately.

The article also covers identifying triggers like recent updates, driver changes, or idle crashes, plus collecting dump files and determining whether the root cause is hardware or software. If your system keeps restarting with this specific error, matching your current boot behavior to the outlined patterns narrows down the fix faster than generic troubleshooting checklists.

What should I do if Windows keeps restarting with the same stop code?

If the same stop code repeats, stop broad troubleshooting and make the crash reproducible in the safest way possible. Use Safe Mode if needed, keep a tight record of changes, preserve dump files, and focus on the single domain that matches both the code family and the crash context.

Why repeatability changes the diagnosis

One-off BSODs happen after a bad update, a brief power event, or temporary corruption. Repeated identical crashes are more valuable because they point to a stable trigger: a device path, driver, boot phase, hardware condition, or power-state transition.

If the code changes every time, broad memory corruption is back on the table. If the code and module stay the same, the case for a specific driver or device gets much stronger.

Use Safe Mode to break the loop

If Windows crashes before sign-in, force entry into recovery, then boot Safe Mode. On Windows 10 and 11, I usually interrupt boot three times to reach Windows Recovery Environment, open Troubleshoot > Advanced options > Startup Settings, restart, and pick Safe Mode so I can remove the newest trigger safely.

When recurring restarts justify escalation

Escalate when the same code returns after one careful change, when the crash blocks normal startup, when storage or hardware patterns appear, or when support staff need proof before replacing parts. That is the point to preserve dumps, collect module names, and compare bug check parameters across crashes.

Diagnosing and Resolving the 0x00000011 Stop Code

Encountering stop code 0x00000011 requires looking closely at the specific failure context, such as whether it appears during Windows startup, an application update, or a recent system installation. Guessing the root cause often leads to unnecessary downtime or data loss.

To bypass trial-and-error troubleshooting, follow the steps outlined in the 0x00000011 error guide. It provides a structured triage path to determine if Windows system files are damaged, helps you safely roll back faulty installations, and shows how to inspect application logs for the exact trigger.

How do I use Event Viewer or dump files to identify the cause?

Use Event Viewer for timing and surrounding warnings, then use dump files for the real kernel evidence. Event Viewer can show when the system crashed or rebooted, but dump analysis shows the bug check, its parameters, and often the faulting thread or module. For recurring BSODs, dumps matter more.

What Event Viewer is good for

Event Viewer can confirm whether disk, controller, driver, or service warnings appeared around the crash window. It also helps tie BSODs to resume events, failed driver starts, or storage resets. I treat it as context, not proof.

Why dump files matter

Dump files contain memory contents from the failure time. That gives the kernel view Event Viewer lacks. For recurring crashes, kernel-mode dumps are especially useful because they capture the layer where driver, memory, storage, and interrupt faults usually reveal themselves.

Using WinDbg and !analyze

WinDbg can display bug check information with the !analyze extension. That output shows the bug check code, parameters, and often a probable module. I keep the raw bug check line, all parameters, and any module name exactly as shown so I can compare later dumps cleanly.

Do not blame the named module too early. A storage driver may be named because it hit corrupted data from RAM, and a kernel service path may be named because a third-party filter driver fed it bad input. Repetition across several dumps is what gives module names weight.

When is a BSOD more likely hardware, driver, or software related?

A BSOD leans toward drivers when it starts after an update, device change, or sleep-resume path; toward hardware when it repeats under load or across clean software states; and toward software or system files when it follows recent installs, failed updates, or boot corruption without a clear hardware pattern.

Signs that point toward drivers

Crash started after one driver update or one device install.
Safe Mode is stable.
The same module name appears in more than one dump.
Crashes follow docking, Wi-Fi use, USB devices, gaming, or resume.

Signs that point toward hardware or firmware

WHEA_UNCORRECTABLE_ERROR repeats.
Crashes happen under load, heat, or power-state changes.
Different stop codes appear with no software pattern.
Driver rollbacks and Safe Mode do not change the failure behavior.

Signs that point toward software or system files

CRITICAL_PROCESS_DIED follows a failed update or rollback.
INACCESSIBLE_BOOT_DEVICE appears after storage driver changes.
System Restore reverses the issue.
A low-level utility or security product was added just before the crashes.

Full stop code list by failure domain

Memory and paging stop codes

MEMORY_MANAGEMENT — memory corruption, RAM instability, paging trouble, or a driver writing where it should not.
PFN_LIST_CORRUPT — page frame database corruption, often linked to RAM faults or bad kernel drivers.
PAGE_FAULT_IN_NONPAGED_AREA, invalid memory access in nonpaged memory, caused by RAM, drivers, or storage-fed corruption.

Driver and kernel execution stop codes

IRQL_NOT_LESS_OR_EQUAL, invalid kernel memory access at the wrong interrupt level; often driver-led.
SYSTEM_SERVICE_EXCEPTION, fault during a system service transition; check recently changed drivers and filter software.
KMODE_EXCEPTION_NOT_HANDLED, unhandled kernel exception, commonly tied to unstable drivers.
DRIVER_POWER_STATE_FAILURE, driver fails a sleep, shutdown, or resume power transition.

Storage, file system, and boot stop codes

INACCESSIBLE_BOOT_DEVICE, Windows cannot reach the boot volume during startup.
NTFS_FILE_SYSTEM, file system corruption or lower storage-path trouble.
DPC_WATCHDOG_VIOLATION, storage stalls, controller path issues, or hung drivers during power transitions.
CRITICAL_PROCESS_DIED, required system process terminated; often follows system-file, boot-path, or storage trouble.

Hardware, firmware, and security or virtualization stop codes

WHEA_UNCORRECTABLE_ERROR, hardware error record reported by the platform; suspect CPU, board, memory path, PCIe device, or firmware settings.
SECURE_KERNEL_ERROR, low-level security or virtualization stack fault; review recent security, virtualization, and firmware changes.

Frequently asked questions

What does a BSOD stop code mean in Windows?

A BSOD stop code is the label Windows gives a kernel halt. It may appear as a hexadecimal value beginning with 0x, descriptive text, or both. It identifies the crash family and narrows the likely domain, but it does not always prove the exact bad file, device, or component.

How do I find the exact stop code from a blue screen?

Read the stop screen first, then confirm it after reboot in Reliability Monitor, Event Viewer, and memory dump analysis. Record the exact wording, any 0x code, any named driver or module, the crash timing, and what changed recently before trying broad repairs.

What are the most common Windows BSOD stop codes?

Common examples include IRQL_NOT_LESS_OR_EQUAL, MEMORY_MANAGEMENT, PFN_LIST_CORRUPT, PAGE_FAULT_IN_NONPAGED_AREA, SYSTEM_SERVICE_EXCEPTION, KMODE_EXCEPTION_NOT_HANDLED, CRITICAL_PROCESS_DIED, INACCESSIBLE_BOOT_DEVICE, DPC_WATCHDOG_VIOLATION, DRIVER_POWER_STATE_FAILURE, and WHEA_UNCORRECTABLE_ERROR. Each points to a different failure domain and best first test.

How do I fix IRQL_NOT_LESS_OR_EQUAL on Windows 11?

Start with recently changed drivers, especially GPU, chipset, network, VPN, storage, and security products. Check Device Manager, roll back the newest driver, and test sleep and resume if that is when the crash happens. If the issue persists, check RAM stability and collect dump files.

How do I fix MEMORY_MANAGEMENT or PFN_LIST_CORRUPT errors?

Return memory settings to default, remove recent RAM changes, and look for signs that a driver is corrupting memory. If the timing started after driver or utility changes, reverse those first. If the crashes keep repeating, preserve kernel dumps and compare whether the same module appears.

What basic steps should I try before advanced debugging?

Boot Safe Mode if needed, remove new hardware, undo recent driver or utility changes, check Device Manager for exclamation marks, install pending Windows updates, confirm enough free disk space, and use System Restore if the crash began after a clear recent change. Then move to dump analysis if repeats continue.

What should I do if the PC restarts too quickly to read the blue screen?

Use the dump file, Reliability Monitor, and Event Viewer after reboot to recover the stop code and timing. If the system is looping too fast, enter Windows Recovery Environment and boot Safe Mode first. My goal is always to capture the code before making more changes.

Can a BSOD be caused by a Windows update?

Yes, especially when the timing lines up with a new cumulative update, optional driver, or a failed rollback. I treat update-linked crashes like any other change window: confirm timing, test Safe Mode, remove the newest trigger if possible, and use System Restore when rollback options are cleaner.

When should I use Safe Mode for BSOD troubleshooting?

Use Safe Mode when Windows crashes before sign-in, shortly after the desktop appears, or whenever you need to remove a suspect driver or utility without loading the full third-party stack. If Safe Mode is stable, that strongly supports a driver, startup, or filter-level problem.

When should I move from basic troubleshooting to dump-file analysis?

Move to dump analysis when the same stop code repeats after one careful change, when normal boot is blocked, when a module name appears more than once, or when you need evidence before replacing parts. Repetition is the main reason I stop guessing and start comparing dumps.

Is WHEA_UNCORRECTABLE_ERROR usually a hardware problem?

Often yes, but not automatically. WHEA pushes the diagnosis toward hardware or firmware, especially if crashes happen under load, heat, or wake events. I still reset firmware settings, remove new hardware, and confirm the pattern before concluding that a CPU, motherboard, or PCIe device is bad.

Do different stop codes on different days usually mean bad RAM?

They can, especially when the codes vary across unrelated tasks and no single driver pattern stands out. Mixed stop codes also appear when a storage path is unstable or a low-level driver corrupts memory broadly. I treat changing codes as a reason to test memory, storage, and recent drivers together.

What if no dump file is created after the crash?

No dump is still useful evidence. It can point to paging issues, abrupt power loss, storage problems, or a crash path that interrupts writing the file. I verify free space, check storage health and system stability, then try to reproduce the crash again before changing too many variables.

Should I replace hardware after one BSOD?

Usually no. One crash can come from a bad update, one-time corruption, or a temporary power event. I only jump toward hardware replacement when the same pattern repeats, WHEA keeps returning, load-related failures persist, or dump and timing evidence keep pointing back to the same physical component.