Windows BSOD crash loop: how to reach Safe Mode and break the restart cycle

A crash loop is a cycle, not a single event: Windows starts, a component that loads early — a driver, a system file, an update's payload — does something it shouldn't, the kernel raises a stop error, and a setting called "Automatically restart" reboots the machine before the blue screen has been visible for more than a second. The next boot hits the same component, raises the same stop error, and the cycle repeats. From your chair it looks like a machine that "just won't start," but underneath it's booting the same broken configuration over and over.

Two consequences matter for everything that follows. First, the stop code is usually unreadable in a loop, which is why this guide starts with recovery access rather than "write down the code." Second — and this is the part people get wrong — interrupting the loop does not fix the loop. Holding the power button, pulling the plug, or forcing a shutdown stops the current attempt; it does nothing about the component that will crash the next one. The machine is still holding the same broken state in storage, and it will resume the moment it powers on again.

That's also why the goal is phrased as "get somewhere you can act" instead of "turn it off." You have three realistic destinations when the desktop is unreachable: the Windows Recovery Environment (the blue "Choose an option" menu), Safe Mode (Windows with almost nothing loaded), or a previous working state via System Restore. Each opens a different set of tools, and the sections below are ordered by which one you need first. The schematic shows the cycle and the three exits.

The Windows Recovery Environment is the blue "Choose an option" screen — the menu with Continue, Troubleshoot, and Shut down/Restart. It runs before Windows itself starts, so it's usable even when Windows can't. Everything in this guide (Safe Mode via Startup Settings, update removal, System Restore, Startup Repair) is reachable from that screen, which is why reaching it is the real first task. Technically, "Advanced startup" is the general name for the boot process that leads there, and "Advanced options" is the submenu inside WinRE — you'll see all three terms used for related screens, and that's normal, not a mistake in the steps.

Windows gets you there in a few different ways, and which one applies depends on how badly the loop is behaving. If the machine has been crashing on startup a few times in a row, Windows often enters WinRE on its own and shows the "Automatic Repair couldn't fix your PC" screen — at which point you simply choose Troubleshoot. If it isn't, you force it. The three reliable methods, from least to most forceful:

1. Shift-restart from a sign-in or start menu. If you can see the sign-in screen (or the Start menu on a PIN-protected desktop), hold Shift and click Power → Restart. The machine reboots straight into "Choose an option." This is the cleanest path and the one to try first.
2. Interrupt startup. If you can't even reach the sign-in screen: power the machine on, and the moment you see the Windows logo (or the manufacturer's logo giving way to the spinning dots), hold the power button down until it's off. Repeat two or three times. On the following boot, Windows shows "Preparing automatic repair," then "Choose an option." This is deliberate — you're making Windows conclude the boot is failing.
3. Recovery media. If neither of the above reaches WinRE (the machine won't even get to the logo, or WinRE itself is damaged), create a Windows installation USB on another PC, boot from it, and choose Repair your computer. This lands you in the same "Choose an option" environment. The section Safe Mode itself fails or Windows can't reach Startup Settings covers this path in detail.

Once you're at "Choose an option," the route for everything in this guide is the same three clicks: Troubleshoot → Advanced options → Startup Settings → Restart. Two practical notes. First, the interrupt method can cause an unplanned shutdown, which on a mechanical hard drive carries a small risk of file-system wear — it's still the right tool here, just don't make it a habit. Second, if the machine has a fast-boot (UEFI) configuration, the logo appears for only a moment; if you keep missing the window, method three (media) is the reliable fallback rather than more guessing at the timing.

After Troubleshoot → Advanced options → Startup Settings → Restart, the machine reboots to a numbered list (the exact numbers can shift slightly between Windows 10 and Windows 11 — read the labels, don't memorize keys). The options that matter for a crash loop are the three Safe Mode variants, plus a couple you might see. Choosing well here saves a full reboot cycle, because getting a Safe Mode variant wrong means restarting and picking again.

The working default is plain Safe Mode: it loads the smallest possible set of drivers and services, which means the least chance of re-triggering whatever is causing the crash, and the least third-party software running while you work. The networking and command-prompt variants add capability — and add exactly the kind of drivers that are sometimes the culprit, so there's a reason not to reach for them reflexively.

You've covered the route (WinRE → Startup Settings), so here is what actually changes once Safe Mode is running, and why it's the room where the fixing happens. Safe Mode is a deliberately stripped-down boot: only the drivers and services Windows considers essential. No graphics drivers beyond the basic display adapter, no audio, no third-party startup items, no startup apps, and (in the plain variant) no network. The desktop may look coarse — low resolution, a "Safe Mode" label in the corners, missing fonts smoothing — and that's expected, not a new problem.

The reason this matters for a crash loop is that most crash-loop triggers don't load in Safe Mode. A misbehaving graphics, network, or storage driver, a bad Windows feature that hooks into startup, a rogue startup app — none of them are present. So if Safe Mode boots and stays up, you've learned something concrete: the fault lives in something that only loads in normal mode, which points straight at a driver, an update, or installed software. If Safe Mode also crashes, you've learned the opposite, and that's a meaningful diagnostic result in its own right (covered in section 9).

One expectation to set: Safe Mode does not fix the BSOD. It gives you a stable environment in which to fix it. Booting in Safe Mode, rebooting normally, and finding the same crash means nothing has changed yet — the trigger is still installed. The next sections are about what to do while you're in that stable window, because it's the window where reversible fixes (uninstall an update, roll back a driver) are safe to attempt.

Safe Mode with Networking is the same stripped-down boot, plus the network stack: the drivers and services needed to reach the internet. That single difference is the whole decision. Use it only when a specific step in your plan requires a connection — downloading the correct driver from the vendor's site, fetching a manufacturer's diagnostic tool, or checking for a known-good driver version. If the step you need to take (uninstalling an update, rolling back a driver, running System Restore, disabling a startup item) doesn't need the internet, plain Safe Mode is the better choice, full stop.

There are two reasons to be deliberate about this. First, the network drivers are themselves a common class of crash-loop cause — a bad Wi-Fi or Ethernet driver update can be exactly the thing crashing your machine. Loading them on purpose, before you've established they're innocent, can turn a stable Safe Mode session into another crash and erase the evidence you were trying to gather. Second, a machine mid-troubleshooting that's also browsing the web is a machine doing two things at once; keep the session as quiet and controlled as the situation allows.

The practical pattern: start in plain Safe Mode, and if a step genuinely needs a download, reboot once into the networking variant, do that one step, and return to plain Safe Mode to continue. It costs a reboot cycle, but it keeps your diagnosis clean. If you find yourself wanting the network for "just in case," that's the signal to pick plain Safe Mode — you can always come back.

You have a stable desktop that, in normal mode, would crash. Use that window in an order that goes from "most likely, easiest to reverse" to "heavier." The instinct to jump straight to the fanciest tool is the one that wastes crash-loop sessions, because the most common cause — a recent change — is also the easiest to undo and the easiest to prove.

1. Establish the timeline. Before changing anything, note when the crashes started and what changed around that time: a Windows update (Settings → Windows Update → Update history), a driver update, a new app or device, a BIOS/firmware change. This single fact decides which of the next steps is the real fix.
2. Check the update history and, if a quality update lines up with the first crash, remove it — the procedure is in section 7. This is the single highest-yield move for update-caused loops.
3. Look at recently installed or changed drivers. In Device Manager, anything with a recent date — and especially graphics, network, storage, or chipset drivers — is a suspect. Rollback or reinstall from the vendor is covered in section 8. Do not delete drivers indiscriminately; a rolled-back driver is reversible in a way a removed one isn't.
4. Check startup items. Task Manager → Startup, and note anything added around the crash date. Disable (don't uninstall) the newest ones so the change is easy to reverse if it wasn't the cause.
5. Check reliability and event information. The Reliability History view (search "View reliability history") and Event Viewer's System log around the crash timestamps often name the failing component or service, and confirm your timeline. This is evidence, not guesswork.
6. If the cause still isn't obvious, run the integrity checks below, and consider System Restore to a point before the first crash (recovery → section 7 lists it as an option; it's also reachable in Safe Mode via search for "Create a restore point").

The two integrity checks are safe, built-in, and worth running while you have a stable session. They only restore correct versions of protected files and touch nothing of yours. Run DISM first (it repairs the image SFC draws from), then SFC:

Finish the session by re-testing in normal mode — but deliberately. Boot normally and reproduce whatever you were doing when the crashes happened. A fix is verified by the same stop code not returning over real use, not by a single clean boot. If it's stable, you're done and the prevention items in section 15 are worth doing; if it crashes again, you've narrowed the field and section 9 is where to go.

When the crash loop started shortly after a Windows update, removing that update is often the entire fix — which is why it comes before most other options. But "recent update" covers two very different kinds of update, and they're removed differently, with different levels of reversibility. A quality update is the regular monthly (or out-of-band) security and bug-fix release; it shows in Update history with a "KB" number and a date, and it can be uninstalled. A feature update is a major version bump (for example, moving from one Windows 11 version to the next); these are generally not uninstallable from Settings once applied — you either wait for the built-in "go back" window or use a restore point or a clean install.

From the recovery environment, the path for a quality update is Troubleshoot → Advanced options → Uninstall Updates → Uninstall quality updates, which lists recent quality updates with their dates and KB numbers. Pick the one that lines up with when the crashes began, confirm, and let it finish; the machine reboots afterward. (There's also an "Uninstall feature updates" entry, but as noted, a feature update usually can't be removed this way — it's the restore point or the reinstall that applies there.) If the machine can reach Safe Mode instead, the same removal is available from Settings → Windows Update → Update history → Uninstall updates, which is a slightly more comfortable place to do it.

Two cautions keep this step safe. First, remove one update at a time and re-test. Removing three updates and finding the machine stable tells you none of them individually was the cause — you've just created three new unknowns. One at a time is slower and is the only version that identifies the culprit. Second, removal is a rollback of system components: it's reversible (the update can be reinstalled) and it doesn't touch personal files, but it's still a system change, so a restore point or the backup reminder from the top of this guide applies. If uninstalling the update doesn't stop the loop, that's a result, not a failure — it means the update wasn't (or wasn't only) the cause, and section 9 is next.

If the timeline points at a driver or an application rather than a Windows update, Safe Mode is the tool that lets you prove it and undo it. The logic is the same as before: a driver or app that crashes normal mode usually isn't loaded in Safe Mode, so a stable Safe Mode session after a driver change is strong evidence that the driver is the cause. From there, the fix is a targeted rollback or replacement of that one driver — not a sweep of driver changes.

In Device Manager, the relevant suspects are the classes that load early and touch core resources: display adapters (graphics), network adapters, storage controllers, and system devices (chipset). For the one you suspect, right-click → Properties → the Driver tab offers Roll Back Driver when a previous version is available — this is the cleanest option because it's a single, reversible step back to the version that was working. If there's no rollback available (a fresh install, or the previous version wasn't kept), the alternative is to uninstall that driver and let Windows reinstall its generic version on the next boot, or install the vendor's known-good version — which is the one legitimate reason to use Safe Mode with Networking.

Please resist two tempting mistakes here. The first is indiscriminate driver removal: deleting several drivers (or running a third-party "driver cleaner") turns one testable hypothesis into a pile of unknowns, and removing a driver Windows expects can make booting harder, not easier. The second is trusting random driver installers — downloadable "driver updater" utilities are a frequent source of exactly the instability they claim to fix. Get driver software from the hardware manufacturer's site or from Windows Update, full stop.

For an application rather than a driver, the same Safe Mode window is where you uninstall it (Settings → Apps, or the newer "Apps & features"), and where you disable recent startup entries in Task Manager to test them. The broader "what to undo first" reasoning — building the timeline, ordering the candidates, verifying — is laid out in the companion guide BSOD after a Windows update, driver update, or new software install, and driver-specific detail (GPU, network, storage, chipset) is in BSODs caused by drivers. After any change here, the test is the same: reboot normally and confirm the stop code doesn't return.

First, be precise about what "didn't fix" means, because the two cases lead different directions. If you could get into Safe Mode, it stayed stable, you made changes, rebooted normally, and then it crashed again — the changes didn't hit the cause, and you now have a shorter list to work from (the update and the top driver suspect are ruled out). That's progress, and the answer is to go one level deeper, not to restart the whole process from the top. If, instead, Safe Mode itself crashes, that's a different and more informative result, and it's handled in section 10.

When a stable Safe Mode session plus the usual reversible fixes (update removal, driver rollback, startup cleanup) hasn't stopped the loop, the cause is more likely to be something that loads even in a minimal boot, or something physical. The realistic candidates, in rough order of how worth-checking they are: a driver that loads even in Safe Mode (some storage and system drivers do), corrupted system files (the DISM/SFC checks from section 6 are your first look here), a degrading storage drive (a drive that's failing can crash on the reads Windows does at boot), unstable RAM (memory faults show up as crashes with no clean pattern), and firmware or power issues (a recent BIOS change, or marginal power delivery).

The escalation path from here is deliberate and evidence-based, not a scramble: (1) confirm the integrity checks' results and finish them if they were interrupted; (2) run the memory and disk diagnostics — mdsched.exe for memory, and the disk-health check below; (3) read the crash dumps, because by this point the minidumps are your best evidence of a repeated faulting module (investigating repeated BSODs with minidumps); and (4) only if a specific component's test comes back bad, address that component — with a backup done first. A single clean test result doesn't clear a component; a repeated, specific failure is what earns a replacement.

Two links carry this forward properly rather than repeating their steps: if the evidence points at the drive, storage and file-system BSODs; if it points at memory, memory-related BSODs. And if the software-level options are genuinely exhausted, the final-recovery path (System Restore, repair install, clean install, in that order) is the BSOD recovery checklist.

This is the branch where the normal plan hits a wall: you select a Safe Mode option and it crashes anyway, or the machine won't even get to the "Choose an option" / numbered menu. Both are recoverable in most cases, but they move your workspace out of Windows entirely and onto the Windows Recovery Environment — ideally one booted from installation media, because if the local copy of recovery is part of the problem, the USB copy is not. The section on reaching WinRE has the media method; here's what to do once you're in it.

Work the Advanced options menu from least to most invasive. Startup Repair is the automatic attempt to fix startup files — worth one run if you haven't, though it resolves fewer real-world cases than its reputation suggests. System Restore is often the actual answer in this branch: if a restore point exists from before the first crash, restoring to it rolls back system changes (updates, drivers, apps) without touching personal files, and it can resolve loops that Safe Mode couldn't even enter. Uninstall Updates is also available from here, so you can remove the suspect quality update without ever reaching a desktop. Each of these reboots the machine; after each one, let it attempt a normal boot and see if the loop is broken before moving to the next option.

If those don't hold, the Command Prompt in Advanced options opens onto the installed Windows (if it can load far enough) or a recovery console, where the integrity tools and disk checks from the earlier sections can run in a form that doesn't need a working desktop. One important warning about what not to run here: DISM has an /Image: mode that operates on an offline Windows installation, and it is not the same as the /Online repair you run in a live system. The live commands from section 6 assume a running Windows; in a recovery console, use the documented offline forms and verify exactly which installation you're targeting before you run anything that modifies it. When the local recovery options are exhausted or the drive is suspected, the next tier is a repair install (reinstalling Windows over itself from the same media, preserving files) and, last, a clean install — both covered in the recovery checklist, and both reasons to have the backup from the top of this page already done.

If even a boot from known-good installation media can't get past the early stages, or the machine behaves differently on every attempt, that's the point at which the cause is more likely hardware than software, and section 12 is the honest next place to look — with data protection, not part-swapping, as the priority.

The single most useful thing a crash loop can do for you is show you the stop code — and the "Automatically restart" behavior is exactly what hides it. This setting, when on, reboots the machine within a second or two of a critical error, which is why a looping PC often appears to just "keep restarting" with no blue screen you can read. Turning it off doesn't change the crash; it changes what you can see about it. That's a small but real diagnostic gain, because the stop code is the input to everything in the blue screen guide.

There are two ways to reach the setting, depending on how far the machine still boots. If it reaches the desktop even briefly, or the sign-in screen: Settings → System → About → Advanced system settings (or search "View advanced system settings"), then the Startup and Failure section — uncheck Automatically restart and confirm. The wording is essentially identical in Windows 10 and 11, though the route into it moved slightly between the two. If the machine can't reach the desktop at all, the same option is available from the numbered Startup Settings menu (section 3 lists it as its own entry, usually labelled Disable automatic restart on system failure) — select it, and the next crash will hold the blue screen on long enough to photograph or transcribe the stop code and the bugcheck value.

State the limitation plainly, because it's the difference this setting makes and the one it doesn't: disabling automatic restart makes the stop code visible; it does not repair the cause. The machine will still crash, and will still fail to reach the desktop — you'll just be able to read why on each attempt. Treat it as a way to feed the stop code into the reading guide and the decision tree below, then return to the actual recovery work. (Leaving it off afterward is a reasonable habit for a machine under diagnosis; there's no need to flip it back until the crashes are gone.)

Software causes dominate crash loops, and you should keep pursuing them first. But a loop has a signature that increasingly points at hardware, and recognizing it saves you from reinstalling Windows onto a machine with a failing drive. The signature is a combination of: the loop persists across all software fixes (update removed, drivers rolled back, a clean Windows still crashes), it may behave differently on each attempt, and it often correlates with load or heat. At that point the productive question shifts from "what's installed" to "what's physically failing or marginal."

The hardware suspects, and the diagnostic that speaks to each, are worth naming specifically rather than gesturing at "it's probably a part." RAM: memory faults produce crashes with no clean pattern and can appear in Safe Mode; the test is the memory diagnostic (mdsched.exe, section 9), ideally extended, and testing modules one at a time if there's more than one stick. Storage: a degrading drive can crash on the reads Windows performs at boot; the check is the disk-health status (section 9), and a "pred-fail" reading is a replace-and-back-up decision, not a repair task. Overheating: sustained heat under load can cause both hard shutdowns and, less often, blue screens — check temperatures under load and whether the machine runs hot when it fails, as detailed in the overheating guide. Power: marginal or unstable power delivery (a failing supply, a weak outlet/cable) tends to produce shutdowns under load more than clean stop codes, but it's part of the same "does it fail under load?" question.

Two more hardware-adjacent causes are common and easily overlooked. Firmware: a recent BIOS/UEFI update, or a BIOS setting that was changed (an overclock, an undervolt, a memory profile), can destabilize a machine that was fine before — the safe move is to reset the firmware to defaults and re-test before touching anything else, since it's a free, reversible change. Recent physical changes: a newly added or reseated component (RAM, a drive, a GPU) that's incompatible or not fully seated is a classic cause of a loop that started the day hardware was touched. None of these tests proves a part has failed; a memory test that errors, or a disk that reports pred-fail, is what moves a component from "suspect" to "the cause." Until a specific test says that, the responsible step is the next one — when to stop and escalate — which is about protecting data and getting expert help, not about swapping parts on a hunch.

If you'd rather have a route than a map, answer a few questions and this points you to the right section above — or the right guide in the series. It matches symptoms to the least invasive appropriate step, which is the whole discipline of recovery: do the reversible thing first.

The same logic as a quick table, for reference:

Most failed crash-loop recoveries aren't failed because the right tool was unavailable — they're failed because a fast, irreversible, untestable move was made before a slow, reversible, testable one. The recovery discipline is entirely about ordering: reversible before irreversible, one change at a time, verified. These are the moves that break that discipline, and each one is worth avoiding specifically because it converts a diagnosable situation into a confused one.

• Random driver installers and "driver updater" utilities. Third-party driver sweepers are a leading cause of the exact instability they promise to cure, and they change many drivers at once — which destroys your ability to tell which change helped or hurt. Use the vendor's site or Windows Update, one driver at a time.
• Repeated hard power-offs. Interrupting the loop doesn't fix it (section 1), and doing it in a panic loop wears on the process and, on a mechanical drive, on the disk. Power-interrupt is a tool for reaching recovery (section 2), used deliberately a few times — not a treatment you repeat hoping for a different result.
• Deleting system files to "clear things out." There is no safe, general version of this. Removing files you can't name from C:\Windows can turn a recoverable loop into a non-booting system. The safe integrity tools (DISM, SFC) restore correct files; they don't let you delete arbitrary ones.
• Blindly editing the registry. Registry "fixes" found by searching a symptom are untestable and often wrong, and a bad edit in the wrong key can prevent Windows from starting at all. If a specific, verified fix requires a registry change, it comes from a trusted, specific source for your exact situation — not a generic snippet.
• Reinstalling Windows repeatedly without a diagnosis. A clean install fixes the OS layer and none of the others: it won't fix a bad driver that reinstalls, unstable RAM, or a failing drive. Reinstalling twice and still looping is strong evidence the cause isn't the OS — at which point the answer is diagnosis (dumps, memory, disk), not a third install.
• Unnecessary BIOS/firmware changes. Tinkering with firmware settings while troubleshooting adds a new, hard-to-reverse variable. The one BIOS move that is appropriate is resetting to defaults (section 12) when a firmware change is a suspect — everything else waits.

The pattern behind all six is the same rule restated: keep every step reversible and singular until you've found the cause, and protect the data throughout. Do that and even a hard loop is a series of small, checkable decisions instead of a gamble.

Every recovery path has a point where continuing solo stops being the best use of the situation, and knowing that point is part of doing this well. The honest escalation criteria are: the loop survives the full reversible software path (update removal, driver rollback, System Restore) and the software-level final options (repair install); a specific hardware test has returned a failure (memory errors, a disk reporting pred-fail); the machine's behavior is inconsistent enough that you can't trust the state you're diagnosing; or — and this overrides the rest — important data is at risk and not yet backed up. At any of those points, the correct next move is not another software trick.

When data protection is the priority, the order is unambiguous: get the files off the drive before anything else. If the machine reaches Safe Mode, copy to an external drive from there. If it doesn't, the realistic options are booting from a live environment or the Windows installation media's command prompt to copy files to external storage, or — for data you can't afford to lose and can't reach — a professional data-recovery service, which is a different and more careful discipline than DIY recovery and is the right call when the drive itself is the suspect. A failed drive that's still "working enough" to read is often a drive that's about to stop working at all; that's the moment recovery pros exist for.

Escalating to professional help (a repair service or, for hardware under warranty, the manufacturer) is a sound decision, not a failure, once the reversible software path is exhausted and a hardware cause is in play — and it's faster than guessing at parts. Going in with the evidence you've gathered makes that help far more effective: the stop code(s) you captured, the timeline of when it started, what you changed, which tests you ran and their results, and what you've already ruled out. The final-recovery software path, if that's where you are, is laid out step by step in the BSOD recovery checklist, and the prevention items below are worth doing the moment the machine is stable again.

This page is the recovery half of the blue screen series. The other eleven cover reading the code, isolating each suspect, and preventing the loop from coming back — jump to whichever matches where you are now.

A crash loop often connects to broader performance and hardware topics. These guides from the wider library naturally follow on.