Windows Update Stuck: Fix It Without Wiping the PC

What “stuck” actually means (and why it’s not always Windows Update)

When people say Windows Update is “stuck,” they usually mean one of these failure modes:

• UI stuck: the Settings app shows a frozen percentage, but downloads or installs are happening in the background.
• Download pipeline stuck: the machine can’t get metadata or content (proxy, DNS, TLS interception, Delivery Optimization weirdness, or corrupted cache).
• Servicing stack stuck: CBS (Component-Based Servicing) can’t apply packages due to component store corruption, missing source files, or a mismatched servicing stack.
• Reboot phase stuck: updates staged, then fail during reboot and roll back in a loop.
• Disk/IO bound: the update is “stuck” because the storage is slow, the disk is full, or the system is thrashing on a dying drive.
• Third-party interference: endpoint security, disk filter drivers, “system optimizers,” or aggressive cleanup tools block updates or delete the wrong state.

The fix depends on which one you’re in. So we don’t start by blindly nuking folders. We start by measuring.

One quote worth keeping on a sticky note:

“Hope is not a strategy.” — paraphrased idea often used in operations and reliability engineering

Also, a short joke, because you deserve one: Windows Update progress percentages are like elevator buttons—pressing them harder doesn’t make it faster.

Fast diagnosis playbook (first/second/third checks)

First: is it actually doing work or just frozen?

1. Check disk activity and CPU in Task Manager (Details view). If TiWorker.exe, TrustedInstaller.exe, or svchost.exe (wuauserv) is busy and disk is active, you may be in a slow-but-progressing phase.
2. Check free disk space. If the system drive is under ~10–15 GB free, updates commonly stall or fail mid-flight.
3. Check whether you’re stuck pre-reboot or in a boot loop. If you’re stuck in “Working on updates” during boot, that’s a different branch than “Downloading 0%” in Settings.

Second: identify the bottleneck category

1. Network path: DNS/proxy/TLS inspection? On corporate networks, this is common. At home, it’s usually ISP DNS, VPN, or a bad cache.
2. Windows Update services state: are the right services running, stuck, or disabled?
3. Component store health: if DISM/SFC are unhappy, stop blaming the Update UI.
4. Storage health: slow or failing disks create “stuck” symptoms that aren’t update-specific.

Third: apply the least-destructive fix that matches the category

1. Safe resets: restart services, clear SoftwareDistribution and catroot2 (the correct way), retry.
2. Repair servicing: DISM RestoreHealth, then SFC, then retry updates.
3. Targeted escalation: analyze logs, isolate a specific KB, use the update catalog/manual install, or do an in-place repair install (still not a wipe).

Interesting facts & historical context (6–10 quick points)

• Windows servicing is older than “Windows Update”: the Component-Based Servicing (CBS) model dates back to the Vista era and still underpins modern servicing.
• The WinSxS folder isn’t a “duplicate files” bug: it’s a component store enabling side-by-side versions, servicing, and rollback—at the cost of complexity and disk usage.
• Delivery Optimization (DO) changed the game: Windows can fetch update content from peers on your LAN (or the internet, depending on policy), which is great until a policy or cache corruption makes it weird.
• Servicing Stack Updates (SSUs) exist because the updater updates itself: when the servicing stack is outdated, it may not be able to install newer packages correctly.
• Cumulative updates reduced “patch Tuesday sprawl”: fewer individual patches, but one broken cumulative can block a lot at once.
• Windows Update uses multiple caches: not just SoftwareDistribution; cryptographic catalogs and BITS state can also be involved.
• WindowsUpdate.log used to be simple: modern Windows generates ETL traces that you convert into a readable log, which is great for engineers and annoying for everyone else.
• Some update failures are really filesystem/driver failures: filter drivers (AV, encryption, DLP) can cause transaction failures that show up as “update stuck.”
• Rollback is a feature with a timer: the system keeps uninstall data for a limited window (varies by version/settings), which affects disk pressure and recovery options.

Hands-on tasks: commands, expected output, and decisions (12+)

All commands below assume you run an elevated shell. If you’re on Windows, run “Windows Terminal (Admin)” or “Command Prompt (Admin).” The prompt label in the blocks is cosmetic; the commands are real Windows commands.

Task 1: Confirm the update-related services aren’t disabled or stuck

cr0x@server:~$ sc query wuauserv
SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

What it means: STATE: RUNNING is good. If it’s STOPPED, that’s fine if updates aren’t in progress; if it’s disabled or failing to start, that’s a problem.

Decision: If wuauserv isn’t running during an update attempt, start it (Task 2) and check dependencies (BITS, cryptsvc).

Task 2: Start core services (Windows Update, BITS, Crypto)

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

What it means: If any service fails, the error text matters. “Access is denied” hints at policy or broken permissions; “dependency service failed” points you to the next link in the chain.

Decision: If services won’t start, don’t delete caches yet; diagnose service configuration, permissions, or corruption first.

Task 3: Check free disk space (the boring killer)

cr0x@server:~$ fsutil volume diskfree c:
Total # of free bytes        :  4294967296
Total # of bytes             : 255852544000
Total # of avail free bytes  :  4294967296

What it means: Here you have ~4 GB free. That’s not “tight,” that’s “update roulette.” Feature updates and cumulative updates can require multiple GB for staging, rollback, and temp extraction.

Decision: If you’re under ~10–15 GB free, stop and free space before doing anything else. Clearing caches without space just creates new failure modes.

Task 4: Quick health check of the system drive

cr0x@server:~$ chkdsk c: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

What it means: If it reports problems, fix the filesystem before blaming update components. Corrupt metadata can break package staging and rollback.

Decision: If errors are found, schedule an offline repair: chkdsk c: /f (it may require reboot).

Task 5: Check the Windows Update client for obvious error states

cr0x@server:~$ usoclient StartScan

What it means: This triggers a scan. It won’t print much. The point is to cause log activity you can inspect.

Decision: If the UI is stuck but a scan triggers new log entries, you’re in “UI stuck” territory; move to log inspection tasks.

Task 6: Get a readable Windows Update log (modern Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log"
WindowsUpdate.log written to C:\Users\Administrator\AppData\Local\Temp\WindowsUpdate.log

What it means: You now have a merged log you can open with Notepad. Look for repeated errors, HTTP codes, proxy issues, or “FATAL.”

Decision: If you see HTTP 401/407/0x8024402c patterns, treat it as network/proxy/DNS. If you see CBS/package failures, go to DISM/SFC.

Task 7: Check BITS queue (download pipeline)

cr0x@server:~$ bitsadmin /list /allusers
BITSADMIN version 3.0
BITS administration utility.
(c) Copyright 2000-2003 Microsoft Corp.

{E3C8D2B4-0D3E-4D3D-9C5C-2AABF5C1A7E1} 'WU Client Download' SUSPENDED 0 / 1 0 / 52428800

What it means: A suspended job can be normal if the network is constrained or the job is paused due to policy. It can also indicate a stuck queue.

Decision: If jobs sit suspended forever, restart BITS and clear problematic jobs (carefully). In most cases, resetting update components (Task 10/11) is cleaner than manually hacking BITS jobs.

Task 8: Check WinHTTP proxy configuration (corporate culprit)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.local:8080
    Bypass List     :  (none)

What it means: WinHTTP proxy is used by system services (including update components) even if your user browser proxy is different.

Decision: If you’re off-network or the proxy is wrong, reset it: netsh winhttp reset proxy. If you are on-network, make sure this matches corporate policy.

Task 9: Confirm system time isn’t lying (TLS and signature verification)

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 9:12:32 AM
Source: time.windows.com

What it means: If time is badly wrong, certificate validation fails and update downloads/signatures can break in non-obvious ways.

Decision: If the sync time is ancient or the source is “Local CMOS Clock,” fix time sync before chasing update ghosts.

Task 10: Stop services before cache surgery

cr0x@server:~$ net stop wuauserv
The Windows Update service was stopped successfully.

cr0x@server:~$ net stop bits
The Background Intelligent Transfer Service service was stopped successfully.

cr0x@server:~$ net stop cryptsvc
The Cryptographic Services service was stopped successfully.

What it means: You can’t safely modify the update cache while the services are writing to it.

Decision: If any service refuses to stop, check for pending reboot or a hung service; reboot once (not five times) and try again.

Task 11: Reset the update caches (the classic, done correctly)

cr0x@server:~$ ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
cr0x@server:~$ ren C:\Windows\System32\catroot2 catroot2.old

What it means: Renaming is safer than deleting. If this fixes the issue, you can later delete the .old folders to reclaim space.

Decision: If rename fails with “in use,” you didn’t stop the right services—or something (security software, filter driver) is holding handles. Investigate before forcing it.

Task 12: Start services and try the scan again

cr0x@server:~$ net start cryptsvc
The Cryptographic Services service was started successfully.

cr0x@server:~$ net start bits
The Background Intelligent Transfer Service service was started successfully.

cr0x@server:~$ net start wuauserv
The Windows Update service was started successfully.

cr0x@server:~$ usoclient StartScan

What it means: This forces a rebuild of caches and metadata.

Decision: If updates now move past 0%/stuck states, you were in cache corruption land. If not, proceed to servicing health checks.

Task 13: Check component store health (DISM)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

What it means: If it says corruption is detected, you need /RestoreHealth.

Decision: If corruption exists, repair it before retrying updates. Windows Update depends on CBS being sane.

Task 14: Repair component store (DISM RestoreHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

What it means: DISM repaired the component store using Windows Update or local sources.

Decision: If DISM fails with source errors (common ones include 0x800f081f), you may need a mounted ISO as a source. Don’t wipe; feed DISM the right files.

Task 15: Repair system files (SFC)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.

What it means: SFC repaired system files. If it can’t repair files, you’ll need to inspect C:\Windows\Logs\CBS\CBS.log and possibly rerun DISM.

Decision: If SFC repairs things, reboot and retry updates. If SFC can’t repair, treat it as deeper servicing trouble.

Task 16: Check for pending reboot state (the silent blocker)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
ERROR: The system was unable to find the specified registry key or value.

What it means: Key not found usually means no CBS pending reboot flag. If it exists, you likely need a reboot to complete a previous install/uninstall.

Decision: If pending reboot is flagged, reboot once, then retry updates. Don’t stack 12 reboots and call it a plan.

Task 17: Inspect update history quickly (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source        Description      HotFixID  InstalledBy          InstalledOn
------        -----------      -------  -----------          -----------
COMPUTERNAME  Update           KB5034123 NT AUTHORITY\SYSTEM 1/30/2026
COMPUTERNAME  Security Update  KB5033375 NT AUTHORITY\SYSTEM 1/15/2026
COMPUTERNAME  Update           KB5032007 NT AUTHORITY\SYSTEM 12/20/2025
COMPUTERNAME  Update           KB5029920 NT AUTHORITY\SYSTEM 11/18/2025
COMPUTERNAME  Update           KB5028851 NT AUTHORITY\SYSTEM 10/22/2025

What it means: You can see whether anything has installed recently. If nothing installs for months, you may have policy blocks or a broken servicing stack.

Decision: If the last update is ancient, prioritize policy/proxy/WSUS configuration checks (Task 18) and servicing health.

Task 18: Check if WSUS/policy is forcing a dead-end server

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    WUServer    REG_SZ    http://wsus.corp.local:8530

What it means: This machine is configured to use WSUS. If you’re not on that network, you’re effectively trying to buy groceries from a store that doesn’t exist.

Decision: In managed environments, don’t override policy casually. In unmanaged machines, removing WSUS policy can restore direct updates, but do it knowingly (and preferably after backing up policy state).

Second short joke, and then we get back to work: Deleting C:\Windows would also “fix” Windows Update, in the same way removing an engine fixes an oil leak.

Checklists / step-by-step plan (safe, then surgical)

Phase 0: Don’t make it worse (5 minutes)

1. Plug in power (laptops). Update failures from battery cutouts are self-inflicted.
2. Disconnect unnecessary USB storage (especially flaky external drives).
3. Pause heavy IO workloads: games downloading, cloud sync, VM disk churn. Updates compete for disk.
4. Take a quick snapshot of reality: note the stuck state (0%, 100%, reboot loop) and any error code.

Phase 1: Fast checks (15–30 minutes)

1. Free disk space to at least 15–20 GB on C: if possible (uninstall big apps, clean Downloads, clear temp). Don’t use sketchy “registry cleaners.”
2. Reboot once. One clean reboot clears a lot of pending transactions and service deadlocks.
3. Check services (Task 1/2). Make sure BITS, cryptsvc, wuauserv run.
4. Check proxy/time (Task 8/9). If time/proxy is wrong, everything else is theater.

Phase 2: Reset update components safely (20 minutes)

1. Stop services (Task 10).
2. Rename caches (Task 11): SoftwareDistribution and catroot2.
3. Start services (Task 12) and trigger scan.
4. Watch behavior: if downloads start moving, you’re likely fixed. Let it run; don’t interrupt for sport.

Phase 3: Repair servicing health (30–90 minutes)

1. DISM CheckHealth then RestoreHealth (Tasks 13/14).
2. SFC /scannow (Task 15).
3. Reboot.
4. Retry updates.

Phase 4: When DISM needs a source (still not a wipe)

If DISM fails because it can’t find source files, use a Windows ISO that matches your build. Mount it (double-click ISO), then point DISM to install.wim or install.esd.

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

What it means: You repaired using local source instead of Windows Update.

Decision: If this succeeds, run SFC again and retry updates. If it fails, you may have a deeper OS image mismatch or disk-level reliability issues.

Phase 5: In-place repair install (the nuclear option that’s not a wipe)

If you’ve repaired the component store, reset caches, validated disk health, and updates still fail, an in-place repair install can replace Windows system files while keeping apps and data. It’s basically “re-lay the OS plumbing” without bulldozing the house.

Rule: Do this only after you’ve collected logs and you’re confident storage is healthy. Repair installs on a failing SSD are how you turn “annoying” into “data loss.”

Common mistakes: symptom → root cause → fix

1) “Stuck at 0% downloading”

Symptom: Download never starts; no network traffic; retries do nothing.

Likely root cause: WinHTTP proxy misconfiguration, DNS issues, TLS inspection breakage, or BITS queue stuck.

Fix: Check proxy (Task 8), time (Task 9), BITS (Task 7). Reset update components (Tasks 10–12) if caches are corrupted.

2) “Stuck at 100% installing” (in Settings)

Symptom: UI says 100% but nothing happens for hours.

Likely root cause: Servicing is happening (slow disk) or CBS is stuck on a transaction.

Fix: Check disk activity; ensure enough free space (Task 3). If it truly doesn’t move, repair servicing (Tasks 13–15).

3) Endless reboot loop after updates

Symptom: “Working on updates” then reboot; sometimes “We couldn’t complete the updates.”

Likely root cause: A specific driver or filter driver breaks during the offline phase; filesystem errors; insufficient space for rollback; broken update package state.

Fix: Boot to Advanced Startup, use Safe Mode if needed, run chkdsk and DISM/SFC. Remove recently added security/driver software if it correlates. Reset update caches once you’re stable.

4) Error 0x800f081f (or “source files could not be found”)

Symptom: DISM fails; updates may fail; SFC can’t repair.

Likely root cause: Component store corruption plus inability to fetch sources (WSUS misconfigured, offline machine, or missing optional feature sources).

Fix: Use a matching ISO as DISM source (Phase 4) or fix WSUS/proxy policies (Task 18 + corporate policy alignment).

5) “Windows Update service missing/disabled” after using a “debloater”

Symptom: Updates never run; services disabled; errors about access denied.

Likely root cause: A script disabled services, changed permissions, or removed scheduled tasks.

Fix: Re-enable services, repair permissions (often easiest via in-place repair install), and stop using “tuning” scripts on machines you need to trust.

6) Update downloads but install fails repeatedly

Symptom: Repeated install attempts, same KB failing.

Likely root cause: Component store issues, driver conflicts, or third-party security software intercepting file operations.

Fix: DISM/SFC; temporarily disable/uninstall third-party AV (if policy allows), then retry. If a single KB is the villain, manually install it or block until a superseding cumulative exists.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

They assumed the update problem was “just the internet.” The helpdesk notes said the laptops were remote, users had home Wi‑Fi, and Windows Update was stuck at 0%. So the first response was predictable: tell everyone to reboot their router, disable VPN, and try again.

It didn’t work. Not for a week. The stuck percentage was consistent, and the error codes were vague enough to be useless without looking at the right logs. An engineer finally checked netsh winhttp show proxy on one of the affected machines. Surprise: a corporate proxy was set in WinHTTP and forced for system services, but the laptops were off-network. Browser traffic worked because the browser used user-level proxy auto-config; Windows Update used the system proxy and tried to reach an internal hostname that didn’t resolve on home networks.

The wrong assumption was subtle: “If the web works, Windows Update must have network access.” In corporate environments, that’s simply not true. System services and browsers can take different network paths and policies.

The fix was simple and boring: when devices are off-network, either ensure the proxy is reachable (via VPN) or reset WinHTTP proxy to direct access. After that, SoftwareDistribution resets were needed on a chunk of machines because the failed attempts left stale state.

The lasting lesson wasn’t about proxies. It was about respecting the separation between user networking and system networking. Windows Update lives in the system world.

Mini-story 2: The optimization that backfired

A desktop engineering team tried to “speed up patching” by leaning heavily into peer-to-peer Delivery Optimization across office floors. On paper it was great: fewer repeated downloads from the internet, faster distribution, and reduced WAN usage.

In practice, the offices had a mix of switches and VLANs where multicast wasn’t relevant but broadcast and peer discovery were… inconsistent. Some subnets had aggressive client isolation, some had endpoint firewalls with mismatched rules, and some had laptops that slept more than they were awake.

The result: a group of machines would attempt to fetch update payloads from peers that were technically “available” in the DO graph but effectively unreachable or too slow. Downloads would start, stall, and sit in a suspended state. Helpdesk saw “stuck at 2%” and blamed Microsoft. Network blamed desktops. Desktops blamed network. You know the dance.

When they temporarily disabled peer caching for the problematic segments—forcing clients to pull from the official source—the issue vanished. Then they reintroduced DO with tighter scoping and saner policies, after actually mapping the network reality instead of trusting a default.

Optimization is great. Premature optimization with distributed systems you haven’t instrumented is how you get a ticket queue that never sleeps.

Mini-story 3: The boring but correct practice that saved the day

A finance department ran a set of line-of-business apps on Windows machines that were patched on a strict schedule. Nothing glamorous: monthly maintenance windows, staged rings (pilot group first), and a clean inventory of disk space and health metrics.

One month, a cumulative update started failing on a subset of machines with install errors and long “installing” times. Because they had baseline telemetry, they immediately noticed that the affected machines shared one boring trait: their system drives had less than 8 GB free. It wasn’t a mystery; it was math.

They didn’t chase registry tweaks. They didn’t run random “Windows Update fixer” executables. They freed disk space using standard cleanup, removed a cached installer package used by an old deployment tool, and expanded a few partitions where the hardware allowed it.

After that, the same update installed cleanly. No in-place repair. No reimage. No weekend lost to guesswork.

The “practice” wasn’t a magic command; it was maintaining boring hygiene: space budgets, staged rollout, and the discipline to measure before acting. In production systems, boring is a feature.

FAQ

1) Is it safe to delete or rename the SoftwareDistribution folder?

Yes, when you stop the update services first. Renaming to SoftwareDistribution.old is safer than deleting because you can roll back if you need to inspect old state.

2) What about catroot2—why does it matter?

catroot2 stores cryptographic catalogs used for signature verification. If it’s corrupted, installs can fail in ways that look like “download stuck” or “install stuck.” Rename it after stopping cryptsvc.

3) DISM RestoreHealth is stuck at 62% (or some other number). Is it frozen?

Often it’s working. DISM progress isn’t linear and can pause while processing large manifests. If disk activity continues and the process CPU time increases, let it run. If it sits for hours with no IO and no CPU, then investigate (disk health, event logs, source availability).

4) SFC says it found corrupt files but couldn’t fix some. What now?

Run DISM /RestoreHealth first, then rerun SFC. If it still can’t repair, inspect C:\Windows\Logs\CBS\CBS.log for the specific files and consider an in-place repair install.

5) Why does Windows Update say 100% but never finishes?

Because “downloaded” and “installed” aren’t the same as “committed.” Updates stage payloads, then apply changes via CBS and sometimes during reboot. Slow disks, low space, or component store issues can make the final commit take ages or fail.

6) Should I use third-party “Windows Update repair tools”?

Usually no. Many are wrappers around the same resets you can do yourself, plus extra “cleanup” that can break servicing or policies. If you’re in an enterprise, they can also violate baseline configuration.

7) I’m on a corporate PC. Can I reset WSUS settings to fix it?

Not without coordination. If policy points to WSUS, there’s a reason (compliance, testing, bandwidth). The right move is to confirm you can reach WSUS (VPN) or get IT to adjust policy for remote scenarios.

8) Does a failing SSD look like “Windows Update stuck”?

Yes. Updates do heavy read/write and integrity checks. A disk with reallocated sectors, IO timeouts, or file system errors can cause installs to hang or roll back. Always rule out disk health when symptoms are weird and slow.

9) Can I fix this without losing my files?

In almost all cases, yes. The main “big hammer” is an in-place repair install, which keeps apps and data. A wipe is for when the OS is beyond economical repair or storage is unreliable.

10) Why do updates sometimes fail after “debloat” scripts?

Because many scripts disable services, remove scheduled tasks, or strip components the servicing stack expects. Windows Update is tightly coupled with OS components; treating Windows like a removable parts bin is how you end up rebuilding it later.

Next steps (keep it fixed)

1. After a successful update, delete the renamed cache folders if disk space matters:
   • C:\Windows\SoftwareDistribution.old
   • C:\Windows\System32\catroot2.old

   Only do this once you’re confident updates are stable.

2. Set a disk space floor: if C: routinely drops under 15 GB free, you will keep reliving this story.
3. Don’t “optimize” update services by disabling them. If you need control, use proper policies and maintenance windows.
4. On corporate machines, verify VPN/proxy posture before patch days. Windows Update’s network path is not your browser’s network path.
5. If you had component store corruption, schedule time to investigate why (disk issues, abrupt power loss, aggressive cleanup tools, filter drivers). Fix causes, not just symptoms.

If you do nothing else: free space, reset update caches the correct way, run DISM RestoreHealth, then SFC. That sequence fixes a surprising percentage of “stuck” systems—without the scorched-earth reinstall.