Emergency Windows Recovery Fix: KB5066189 Restores Reset, Cloud Recovery & RemoteWipe

Microsoft quietly pushed an emergency out‑of‑band update after an August security rollup left some Windows 10 and Windows 11 PCs unable to complete “Reset my PC,” cloud recovery, or MDM RemoteWipe operations — the fix is published as KB5066189 for Windows 11 (with companion OOB packages for Windows 10) and should be installed on affected machines as soon as practical. (support.microsoft.com)

---

Background​

Resetting Windows — whether using the built‑in Reset this PC flow or the cloud-based Fix problems using Windows Update recovery — is a primary self‑service tool for restoring a troubled machine without a full clean install. It’s the fallback many users and IT teams rely on for performance problems, app corruption, malware remediation, and preparing systems for resale or redeployment. The August 2025 cumulative security updates introduced a regression that in some cases caused those recovery flows to start and then abort, leaving devices unchanged and users without the expected recovery path.
Microsoft acknowledged the regression and released targeted, non‑security, out‑of‑band (OOB) cumulative updates on August 19, 2025 to restore the recovery functionality. For Windows 11 the primary remedial package is KB5066189, which updates OS builds to 22621.5771 and 22631.5771; Windows 10 received analogous OOB packages (KB5066188, KB5066187) to cover affected LTSC and servicing branches. Microsoft marked these OOB updates as cumulative and optional for machines that have not seen the recovery failures — but recommended them for systems that have experienced reset or remote wipe failures. (support.microsoft.com, bleepingcomputer.com)

---

Overview: what exactly broke​

Affected workflows​

The regression specifically impacted three recovery-related processes:

• Settings → System → Recovery → Reset my PC (both Keep my files and Remove everything flows)
• System Recovery → Fix problems using Windows Update (cloud reinstall)
• RemoteWipe CSP (MDM‑initiated remote reset/wipe via Intune or other MDM systems)

When triggered on an affected machine, these flows could start but then fail to complete, often returning a message like “No changes were made,” or silently rolling back the operation. The symptom is operationally significant because it converts what should be a quick self‑service repair into a manual, time‑consuming task. (bleepingcomputer.com)

Which updates triggered the regression​

The regression appeared after Microsoft’s August 12, 2025 Patch Tuesday rollups. The problematic originating KBs include variants in that August family:

• Windows 11 (22H2/23H2): the August rollup family identified as KB5063874 / KB5063875. (support.microsoft.com)
• Windows 10 (22H2 and LTSC variants): August rollups such as KB5063709 / KB5063877. (bleepingcomputer.com)

Microsoft’s Release Health advisory and the OOB KBs map those originating updates to the targeted fixes. If your device shows the August build numbers, assume the reset/recovery flows may be affected until the remedial OOB patch is installed.

---

Why Microsoft issued an out‑of‑band fix — and what the OOB contains​

When a monthly security rollup breaks last‑resort recovery tooling, waiting until the next scheduled Patch Tuesday is often unacceptable. Microsoft therefore published OOB updates (KB5066189 for Windows 11 and companion packages for Windows 10) that combine the Latest Cumulative Update (LCU) with a Servicing Stack Update (SSU) in some cases. The SSU helps ensure proper installation sequencing and payload hydration, which is relevant because the failure modes pointed to servicing/packaging or WinRE/component store problems in field analysis. (support.microsoft.com)
Key points about the OOB packages:

• They are non‑security, cumulative updates that supersede the August rollups for the affected servicing branches. (support.microsoft.com)
• They include an SSU component in some combined packages; SSUs are persistent once applied and can complicate rollback.
• Microsoft recommends installing the OOB if you encountered the reset/recovery failures; if you are unaffected and don’t rely on those flows, installation is optional. (support.microsoft.com)

This packaging aligns with how Microsoft typically addresses critical regressions: deliver a narrowly scoped corrective cumulative update as quickly as possible and include servicing stack improvements to increase reliability.

---

How to know if you’re affected (quick checks)​

• Open Start → Run, type winver, press Enter. Note the OS version and OS build (e.g., 22621.xxxx or 19044.xxxx). If your build matches the August rollup builds for your servicing family, you may be affected.
• Go to Settings → Windows Update → Update history and look for August 2025 KBs such as KB5063875, KB5063709, or other August rollup identifiers. (bleepingcomputer.com)
• In PowerShell (Admin) run: Get‑HotFix and inspect the HotFixID list for August KB numbers, or use wmic qfe to query installed packages. This helps confirm whether the August LCU was applied.

If you have attempted a Reset that started and then returned a “no changes were made” result, you were almost certainly affected and should install the OOB fix. (bleepingcomputer.com)

---

Step‑by‑step: install the fix (home users and technicians)​

If you experienced failed reset/recovery attempts, follow these steps in order. Each step is short, conservative, and designed to avoid creating additional complications.

• Back up critical files now. Even though the bug itself does not intentionally delete data, interrupted operations can complicate recovery. Use a file‑copy or full disk‑image backup.
• Check your build and installed August KBs (winver; Settings → Update history; Get‑HotFix).
• Open Settings → Windows Update → Check for updates. In the Optional updates available area, look for KB5066189 (Windows 11) or the Windows 10 OOB (KB5066188 / KB5066187 depending on SKU). Install the available OOB package and restart when prompted. The update is cumulative and will install only the new content it contains. (support.microsoft.com, windowslatest.com)
• If Windows Update does not show the OOB patch, obtain the appropriate standalone MSU package from the Microsoft Update Catalog and install it manually using wusa.exe, then reboot. (Manual catalog retrieval is advanced but common when optional OOBs don’t appear automatically.)
• After the reboot, reattempt Reset this PC or the cloud recovery flow to confirm the fix. If the reset now completes, the OOB resolved the regression. (windowslatest.com)

Important operational notes: because some OOB packages include SSUs, once the SSU portion is applied it cannot be removed separately. That permanence should be considered in enterprise rollback plans.

---

If Reset already failed — recovery options and safe fallbacks​

If you tried Reset and it failed, do not repeatedly retry the same flow without a fallback plan. Instead use one of these safer recovery options:

• Create and boot from official Windows installation media (USB) and use the Repair your computer options or perform an in‑place repair/upgrade that preserves files and apps. This often restores WinRE and component store integrity.
• If preserving data is the priority, attach the drive to another machine (or boot WinPE) and copy files off before further action. Ensure you have BitLocker recovery keys on hand before mounting encrypted volumes.
• Run SFC and DISM to check and repair component store corruption:
• sfc /scannow
• DISM /Online /Cleanup‑Image /RestoreHealth
  These commands can fix certain servicing/component issues that may prevent reset flows from successfully rehydrating required files. Note: DISM/RestoreHealth requires connectivity to a healthy source or Windows update payloads; results vary.

If none of the above helps, a clean install from external media is the reliable fallback — but only after you’ve secured backups and BitLocker keys.

---

Guidance for IT administrators and fleet managers​

Enterprise deployments carry different constraints and risks. The practical playbook for administrators:

• Pilot first. Stage KB5066189 (and the matching Windows 10 OOB packages) to a representative pilot ring that mirrors device diversity (OEMs, firmware, drivers, security agents) and validate Reset, cloud recovery, and RemoteWipe behaviors.
• Pause mass resets/wipes. Do not issue broad RemoteWipe or Autopilot Reset commands to devices that may still have the August rollup but not the OOB fix — unsuccessful wipes leave endpoints in inconsistent states.
• Manage deployment channels carefully. Use Windows Update for Business, WSUS, or Configuration Manager to approve the exact OOB KB that matches your servicing branch and SKU. Obtain the SSU prerequisites noted in Microsoft’s KB and verify combined package behavior.
• Prepare rollback / remediation playbooks. Because combined SSU+LCU packages may be hard to uninstall, ensure you have tested recovery media, golden images, and imaging playbooks if you need to restore a machine. Backups, BitLocker key escrow, and technician readiness matter.
• Track Secure Boot certificate workstreams. Microsoft’s OOB KBs also reiterated guidance about upcoming Secure Boot certificate changes starting mid‑2026; use these deployment windows to validate firmware readiness and certificate management across OEMs. That larger project is separate but operationally related.

---

Risks, trade‑offs, and what to watch for next​

Strengths of Microsoft’s response​

• The vendor delivered a fast, targeted remediation within a week of confirmations — deploying OOB fixes is the right approach for a regression that disables fundamental recovery tooling. This limited, cumulative approach restored the flows without waiting for the next Patch Tuesday. (support.microsoft.com, tenforums.com)

Remaining concerns and tradeoffs​

• Servicing Stack permanence. The inclusion of an SSU in the combined package is pragmatic (reduces future sequencing issues) but it cannot be removed separately, making rollback harder if unexpected interactions occur after deployment. Pilot testing is essential.
• No detailed public post‑mortem yet. Microsoft’s KBs describe the symptom and the fix but do not include a root‑cause engineering write‑up at publication time. Community analyses point to servicing/packaging or WinRE/component store mismatches as likely causes, but those remain field‑level inferences until Microsoft publishes a full technical analysis. Treat specific root‑cause attributions as plausible but not definitive.
• Concurrent storage anomaly reports. While the reset/recovery regression affected many systems, there were separate reports of an unrelated issue on Windows 11 version 24H2 that could cause SSDs/HDDs to disappear and, in some cases, result in data loss. That storage problem appears less widespread but serious enough to merit caution with large file transfers and firmware updates until vendors clarify the cause. Administrators should monitor storage health across fleets and delay risky operations until mitigations are confirmed. (tomshardware.com, itpro.com)

Operational risk summary​

When built‑in recovery tools become unreliable, organizations often resort to ad‑hoc workarounds that can increase support costs, introduce security or compliance gaps (failed remote wipes leave data on devices), and amplify downtime. The combination of a fast OOB fix and conservative rollout/testing will minimize those risks — but organizations still need to exercise care.

---

Practical recommendations (concise checklist)​

• Back up important data and confirm BitLocker key escrow before attempting any recovery or reset.
• Check your OS build and installed August KBs (winver; Settings → Update history; Get‑HotFix).
• If you saw a failed Reset, install the matching OOB package: KB5066189 for Windows 11 (22621/22631 families) or the Windows 10 OOB package for your SKU, then reboot and retest Reset/remote wipe. (support.microsoft.com, bleepingcomputer.com)
• If you haven’t deployed the August rollups yet, prefer the OOB package instead of the original August LCU for affected branches. Stage and pilot in a small ring first.
• For administrators: pause mass remote wipes until your pilot confirms RemoteWipe/Autopilot Reset flows work end‑to‑end post‑OOB. Update deployment runbooks and maintain recovery media for field technicians.
• Monitor Release Health and vendor advisories for any follow‑up known issues and for guidance on Secure Boot certificate transitions. (support.microsoft.com)

---

Final analysis: what this episode means for users and IT teams​

The incident is a reminder of two realities about complex OS servicing:

• Even well‑tested monthly rollups can surface rare but operationally severe regressions once they encounter the real‑world diversity of OEM firmware, drivers, and provisioning images. Recovery tooling is a special‑purpose path that doesn’t get daily exercise on many systems, so regressions there can remain undetected until real usage occurs.
• Microsoft’s decision to publish targeted, combined SSU+LCU OOB updates is appropriate for a bug that undermines recovery paths. The trade‑off is operational permanence (SSU cannot be uninstalled independently) and the need for robust pilot testing before widescale rollout in enterprise fleets.

For most home users who didn’t encounter a reset failure, the immediate risk is low; vigilance and routine backups remain the right posture. For admins and power users who rely on reset, cloud recovery, and MDM wipes to manage lifecycles and compliance, the OOB fixes are essential and should be validated and deployed in a controlled manner.

---

Install the appropriate OOB package if you saw failures; back up before you act; pilot and validate in managed environments; and monitor vendor channels for any follow‑up notes or post‑deployment guidance. The remediation restores critical recovery tooling, but the episode underscores why conservative patching and robust recovery plans matter now more than ever.

---

Source: Windows Central Tried resetting your PC and it failed? You’re not alone — here’s what to do