Windows blue screen with a stop code: diagnose repeated crashes

Classify what actually failed

A stop code is a starting point for collecting evidence, not a reason to apply every repair associated with that name online. Record whether the code repeats or changes, and whether crashes occur at startup, after waking, or during one workload.

If only one application closes while Windows continues running, collect that application’s error instead. If power disappears without a stop screen, inspect power and hardware symptoms; absence of a visible crash screen does not prove a software cause.

Correlate the event with a narrow change

When Windows remains usable, open View reliability history from Start and compare failures with the recorded time. Also review recent driver, application, and Windows update changes. A nearby event is evidence to investigate, not automatic proof of responsibility.

If the failure began with one device driver, inspect its version in Device Manager and consider its available rollback option. Avoid uninstalling unrelated updates or using third-party driver bundles. Keep a way to restore the known driver if the comparison does not help.

Use Safe Mode as a comparison

For a PC that can reach recovery but crashes during normal startup, follow the linked Safe Mode guide. Have the account password and BitLocker recovery information ready before entering recovery.

Stability in Safe Mode narrows the set of software and drivers involved; it does not prove the hardware is healthy because the workload and drivers differ. Compare the same safe action when possible, then return to normal startup and investigate the specific difference.

Escalate hardware evidence before heavy repairs

Changing stop codes, crashes across unrelated tasks, or a recent memory upgrade justify checking the PC maker’s supported hardware diagnostics. Save work before memory tests and protect files before stressing a suspect drive. Record the exact diagnostic result.

Do not use disk repair, repeated stress tests, or Driver Verifier as a casual first step on a machine holding the only copy of important data. If the system also fails outside Windows, prioritize hardware support over operating-system reinstallations.

Preserve useful support evidence

If crashes continue, provide the stop codes, module names, times, recent changes, and Safe Mode comparison to the device maker or administrator. Existing crash dump files may help qualified analysis, but they can contain private information; share them only through a trusted support channel.

A successful restart is not enough to declare the cause fixed. If a repair is proposed, ask which observation supports it and how the result will be tested. Avoid assuming that SFC or a driver update resolves every stop code.

Verification

• Repeat the previously failing ordinary task after one targeted change, without deliberately stressing unstable hardware.
• Check the next normal startup and sleep/wake cycle if those triggered crashes.
• Keep a record of any recurring code; a different code or a longer interval is not yet proof of resolution.

When to stop

Stop if Windows cannot remain stable long enough to protect files, hardware diagnostics report errors, or crashes continue after a justified rollback. Use the startup-repair path for a boot loop and professional recovery for inaccessible important data.

Review the safe troubleshooting workflow before any broader recovery step.