Fix Windows 11 Stuck on 'Getting Windows Ready'

I once left a client's desktop on this screen overnight because everyone online said "wait 2-3 hours" and I didn't trust that number for a machine that had clearly been sitting untouched for months of pending updates. It finished at hour six. Nothing was wrong with it — it genuinely had that much servicing work queued up, on a spinning hard drive, with a feature update in the mix. Had I force-restarted it at hour two the way half the advice out there recommends, I'd have turned a slow-but-fine update into an actual repair job.

That's the uncomfortable truth about this screen: for a real subset of cases, the correct action is to do nothing at all. The hard part is telling that case apart from the one where the machine is genuinely stuck and every additional hour of waiting is wasted time you'll never get back. Here's how to tell the difference, and what to actually do once you've confirmed it's the latter.

What is Windows actually doing during "Getting Windows Ready"?

This screen appears when Windows is applying update changes at boot or shutdown — finalizing file replacements, registering components, and running configuration steps that can't safely happen while the OS is fully running. It is not the same failure mode as a black screen with no disk activity, and it's not the same as a boot loop back to the login screen. Both of those need different troubleshooting than what's below.

The percentage counter, when one shows, reflects configuration steps completing — not raw data transfer — so it can sit at the same number for a long stretch and still be legitimately working. That's frustrating from a user-experience standpoint and Microsoft has taken deserved criticism for offering no more granular status than a percentage that doesn't move in a way that reflects actual progress. But "the UI gives you no useful feedback" and "the process is stuck" are two different problems, and only one of them is fixed by intervening.

How long should you actually wait before doing anything?

For a routine monthly cumulative update, 15 to 30 minutes covers the overwhelming majority of cases. For a feature update (a version jump, like moving to 25H2) or a system that's missed several months of updates and is catching up all at once, 2 to 3 hours is a reasonable, not excessive, expectation — and on an older spinning hard drive rather than an SSD, add more time on top of that; disk I/O speed directly limits how fast configuration steps can complete.

The one signal worth checking before you decide you've waited long enough: disk activity. If your machine has a physical activity LED, watch it — intermittent blinking means something is still reading or writing. If you can't see an LED (many laptops hide it or don't have one), listen for the actual sound of a spinning drive working, or, if you're troubleshooting remotely through something like Boot diagnostics on an Azure VM, check whether repeated screenshots show any visual change at all over a 15-minute window. No change and no detectable activity across that window is the point where "still working" becomes a much weaker explanation than "actually stuck."

People ask if it's safe to force a shutdown — what's the actual risk?

It's not risk-free, but it's also not the catastrophic, always-fatal action some warnings imply. Interrupting Windows mid-write can corrupt whatever file was actively being modified at that instant, which in the worst case is a system file needed for boot. In practice, Windows' update process is designed with some resilience to interruption — it's not uncommon for a forced restart to simply resume where it left off — but "not uncommon to be fine" isn't the same as guaranteed, which is exactly why the check above (confirm no disk activity first) matters more than a fixed time limit. Force-restarting a machine that's actually still writing files is the scenario that turns a slow update into a genuine repair job.

Could a bad network connection actually be the cause?

Yes, in a specific way that's easy to miss. Some configuration steps during this screen check in with Windows Update to confirm certain files or licensing state, and if your network connection is unstable, on a captive portal, or metered in a way that's blocking background traffic, that check can stall rather than fail outright — which looks identical to a stuck screen from the outside. If you're on Wi-Fi, test whether another device on the same network can browse normally; if it can't, the router or modem is worth power-cycling before you assume the PC itself is the problem. If you're on a wired connection, check the physical link. This is worth ruling out before a hard shutdown specifically because, unlike most of the causes here, it's fixed by restoring connectivity rather than restarting anything — and a hard restart while the real problem is "no network" just puts you back on the same screen with the same unresolved cause.

Does this look different on a server or a virtual machine?

On Windows Server, and on VMs generally, you lose the physical disk activity LED as a signal entirely, which removes the easiest way to distinguish "still working" from "stuck." If you're managing a VM through a hypervisor console — Hyper-V, or Azure's Boot diagnostics — the practical substitute is taking screenshots a few minutes apart and comparing them; if the animation, percentage, or any visible element hasn't changed across a reasonable window, treat that the same way you'd treat a dark disk LED. For Azure VMs specifically, if a restore point or recent backup exists, restoring from it is often faster and lower-risk than troubleshooting a stuck boot in place, precisely because you don't have physical console access to try the interrupted-boot method the same way you would on hardware in front of you.

What to do once you've confirmed it's actually stuck

Disconnect peripherals first, before any restart. USB drives, external storage, printers, and even some webcams can interfere with a servicing pass that's trying to detect and configure hardware. Unplug everything nonessential, then proceed.
Perform one hard shutdown. Hold the power button 10-15 seconds until it powers off completely. Wait about 15 seconds, then power back on.
If it boots normally, let Windows Update finish its cleanup on its own rather than immediately digging into settings — a successful recovery from a stuck update sometimes needs one more quiet reboot to fully settle.
If it boots straight back to the same stuck screen, don't repeat the hard shutdown immediately. Instead, use the interrupted-boot method to reach the Windows Recovery Environment (WinRE): power on, and as soon as you see any sign of Windows attempting to load, hold the power button again to force it off. Repeat this cycle two or three times. Windows detects the repeated failed boot attempts and should automatically drop you into WinRE on the next attempt.

You're in WinRE — now what?

From Troubleshoot > Advanced Options, you have several tools, ordered here from least to most invasive:

Startup Repair. Try this first. It's specifically built to detect and fix boot-blocking issues automatically, and it's non-destructive.
Command Prompt, for a manual SFC/CHKDSK pass. If Startup Repair doesn't resolve it, open Command Prompt from the Advanced Options menu and run sfc /scannow against the offline installation, followed by chkdsk /f C: (adjust the drive letter if your Windows partition isn't C: in the recovery environment — check with diskpart and list volume first if you're unsure).
Uninstall the update that triggered this, via Safe Mode. Boot into Safe Mode (Advanced Options > Startup Settings > Restart > press 4 or F4), then go to Control Panel > Programs and Features > View installed updates, and remove the most recent one. This is the step that resolves a genuinely bad or incompatible update, as opposed to a slow-but-fine one.
System Restore, if you have a restore point from before the update began and the steps above haven't resolved it. This rolls back system state to that point, which is broader than just uninstalling one update, so treat it as a step up in invasiveness, not a first resort.
Reset this PC (Keep my files), only if everything above has failed. This reinstalls Windows while preserving personal files, but removes installed apps and settings — treat it as a last resort, not a quick fix, and only after you've confirmed via the steps above that this isn't simply a slow update that needed more time.

What I would not do

Don't force-restart every 15-20 minutes "just in case." Each interruption during an active write is a fresh chance at file corruption. If you're going to intervene, do it once, deliberately, after confirming there's genuinely no disk activity — not repeatedly out of impatience.
Don't pull the battery on a laptop mid-write as your first move. Use the power button first; yanking the battery is a harder interruption with no advantage over a held power button for a system that's already running on it.
Don't jump straight to Reset this PC because a forum thread says it "always works." It does work, because it replaces everything — but it also erases installed programs and settings you may not want to lose, to fix a problem that Startup Repair or an update uninstall often resolves without that cost.
Don't disable your antivirus or firewall as a troubleshooting step here. This isn't a connectivity or permissions problem in the way network and security software issues usually are; it's a boot-time servicing operation, and security software isn't a documented interference point for this specific screen.

When this advice doesn't apply

If your machine shows a black screen with absolutely no text, no percentage, and no manufacturer logo at any point — not even briefly on power-on — that's a different problem (likely a display, boot device, or hardware issue) and none of the steps above are relevant; you're not actually looking at "Getting Windows Ready" if there's no visible interface at all. Similarly, if the machine boots fine but then blue-screens with a specific stop code shortly after, troubleshoot that stop code directly rather than treating it as a variant of this screen — the fixes for a genuine BSOD are different from what's covered here, and applying update-rollback steps to a driver-crash problem won't help.