Windows 11 Blue Screen (BSOD) Troubleshooting: Stop Codes, Dump Files, Drivers, Memory, and Hardware

A Windows 11 stop-code crash is a specific failure mode: Windows detects a serious condition, records a bug check, shows a stop-code screen briefly, and normally restarts. Microsoft also calls this a stop error, kernel error, bug check, or BSOD. On newer Windows 11 builds the screen can be black rather than blue, so the useful identifier is the stop-code event rather than the background color.

Keep neighboring failure modes separate. A machine that instantly loses power, hard-freezes without a stop code, fails POST, or shows a blank display with no fatal-error message belongs to a different diagnostic branch. Microsoft explicitly separates blank-screen troubleshooting from stop-code errors. This page therefore assumes Windows reached the point where a bug check occurred or a crash dump was written.

Record the exact stop code, any hexadecimal bug-check value, any parameters shown by diagnostic tools, and any module or driver name Windows or a debugger identifies. Also record what the PC was doing, whether the failure repeats under the same workload, and what changed shortly before the first crash: a driver, Windows update, BIOS or firmware update, new hardware, memory profile, overclock, undervolt, peripheral, security software, or application.

A repeated code or named module is evidence, not a verdict. Microsoft notes that unexpected restarts can be caused by hardware, a driver, or software, and its bug-check reference treats the code as the detected failure class and context. Do not convert MEMORY_MANAGEMENT into “bad RAM,” IRQL_NOT_LESS_OR_EQUAL into “bad CPU,” or WHEA_UNCORRECTABLE_ERROR into a single-component diagnosis without corroborating evidence.

Windows can write debugging information when a bug check occurs. Microsoft documents small dumps under the configured Small Dump Directory, commonly %SystemRoot%\Minidump, while kernel and automatic dumps normally use %SystemRoot%\Memory.dmp. Dump creation also depends on the configured dump type, available storage, and paging-file or dedicated-dump-file requirements, so the absence of a dump does not prove that the crash was not real or that one component failed.

A dump preserves crash-time state for debugging. A small dump includes the bug-check message and parameters, processor and thread context, the crashing thread’s kernel stack, and loaded-driver/module information. Larger dump types can preserve more kernel or active memory. Preserve the original file before repeated testing when the evidence matters, especially because some dump configurations overwrite the previous Memory.dmp.

Microsoft WinDbg can open kernel-mode crash dumps, and the !analyze -v command provides detailed analysis of the most recent bug check. That can expose the bug-check code and parameters, call stack, modules, and debugger conclusions that are much more useful than guessing from the screen alone.

Even a debugger result still needs interpretation. The module executing when Windows stopped is not automatically the root cause: corruption can occur earlier, another driver can pass invalid data, unstable memory can alter state, or hardware can trigger an error that surfaces later in software. Look for repeatable patterns across multiple crashes, consistent stacks or modules, and correlation with a specific recent change before treating one filename as conclusive.

If the crashes began immediately after a specific driver, Windows update, utility, firmware change, or new device, reverse that change through its supported path when practical and retest the same workload. Microsoft’s stop-error guidance recommends checking recently added hardware, Device Manager, Windows Update, and Safe Mode. Core Tech Tips also has a separate Windows 11 driver-rollback workflow for cases where a known-good previous driver exists.

Safe Mode is useful because Windows starts with a limited set of essential services and drivers. Microsoft notes that if the problem does not reappear there, default settings, basic device drivers, and services can be eliminated as possible causes. That is an isolation result, not proof of one third-party driver. Re-enable or reinstall changes methodically rather than removing several variables at once.

DISM and System File Checker can repair missing or corrupted Windows components and protected system files, and Microsoft currently recommends running DISM before SFC when using that repair path. They are appropriate when other evidence suggests Windows component corruption or system-file damage; they are not universal hardware tests and a clean result does not clear RAM, storage, CPU, GPU, motherboard, power, or firmware.

Avoid registry “fixes,” generic cleaner tools, and third-party driver-updater utilities as first-line BSOD troubleshooting. Also avoid jumping straight to Reset this PC or a clean reinstall. Microsoft’s recovery guidance orders less disruptive options before reset/reinstallation and explicitly warns that some recovery paths can cause data loss. Back up important data before destructive recovery work and keep the BitLocker recovery key available when Windows Recovery Environment may be needed.

Hardware instability can produce bug checks, but test the branch that matches the evidence. Memory-related suspicion becomes stronger when multiple crashes show memory corruption patterns, when errors appear during a dedicated memory test, or when instability follows a memory-profile or module change. Storage suspicion should be tied to storage errors, file-system or device evidence; GPU suspicion to graphics-driver or GPU-load correlation; power and thermal suspicion to repeatable load conditions, telemetry, or shutdown behavior.

Return CPU, GPU, RAM, and firmware tuning to documented defaults when instability began after overclocking, undervolting, XMP/EXPO, curve tuning, or similar changes. Reseat or remove recently added hardware only with the system powered down and according to the manufacturer’s instructions. Do not use one stop-code name as permission to replace parts at random. If a machine is unstable even at documented defaults and repeatable testing implicates hardware, escalate to the component or system vendor with the dump and test evidence.

Use this sequence: 1) capture the exact stop code and failure conditions; 2) preserve available dump files; 3) identify recent software, driver, firmware, tuning, or hardware changes; 4) check supported Windows updates and Device Manager; 5) reproduce in Safe Mode when that comparison is meaningful; 6) analyze repeated dumps with WinDbg if you can interpret them; 7) run targeted software repair or hardware tests based on the evidence; 8) return tuning to defaults; 9) use System Restore, update removal, Windows Recovery Environment, reset, or reinstall only when the less disruptive evidence-led steps justify escalation.

If Windows cannot boot reliably, Microsoft documents Windows Recovery Environment as the built-in recovery hub and may launch it automatically after repeated startup failures. Recovery is still not a substitute for diagnosis: preserve data and crash evidence first when possible, choose the least disruptive supported option that matches the failure, and use professional or manufacturer service when the system cannot be tested safely or hardware failure remains likely.