Windows Recovery Broken After August Patch Tuesday: OOB Fix Incoming

Microsoft has confirmed that a Patch Tuesday update released in August has introduced a serious regression: reset and recovery operations can fail on multiple supported Windows client versions, leaving some machines unable to use the built‑in Reset this PC, the “Fix problems using Windows Update” in Settings, or remote wipe (RemoteWipe CSP) initiated by management tools. The problem affects a range of older-but-still‑supported Windows 10 and Windows 11 client builds, and Microsoft says it is preparing an out‑of‑band (OOB) emergency update to restore recovery functionality. (askwoody.com, support.microsoft.com)

Background / Overview​

Microsoft shipped the August 12, 2025 cumulative updates for multiple Windows client branches as part of Patch Tuesday. Those releases include the combined servicing stack and cumulative update bundles that organizations and consumers install automatically or via management channels. The official update packages for affected clients include KB5063875 for Windows 11 (22H2/23H2) and KB5063709 for Windows 10 22H2/LTSC-related SKUs. These packages deliver security and quality fixes but — in some deployments — have left the recovery pathways broken. (support.microsoft.com)
Microsoft has posted a status update indicating the issue is confirmed, listing affected client platforms and promising an out‑of‑band fix in the coming days. The company’s message specifically describes failures when invoking:

• System > Recovery > Reset my PC
• System > Recovery > Fix problems using Windows Update (the in‑place reinstall/repair option)
• RemoteWipe CSP (Intune/MEM remote wipe) operations

The dashboard entry marked the problem as “Confirmed” and linked the behavior to the August security updates on those client versions. (askwoody.com)

---

Which Windows versions are affected​

Microsoft’s published status (summarized by incident trackers in the Windows admin community) shows the immediate client impact covers several widely used OS builds:

• Windows 11, version 23H2
• Windows 11, version 22H2
• Windows 10, version 22H2
• Windows 10 Enterprise LTSC 2021
• Windows 10 IoT Enterprise LTSC 2021
• Windows 10 Enterprise LTSC 2019
• Windows 10 IoT Enterprise LTSC 2019

At the time of writing, Windows Server SKUs are reported as not impacted by this particular failure mode. Notably, newer Windows 11 version 24H2 does not appear in the affected list, a rare bright spot for organizations on that release. Microsoft’s action plan promised an out‑of‑band update targeted at the affected branches. (askwoody.com, support.microsoft.com)

What’s failing — symptoms and user impact​

The observable symptoms reported by administrators and end users fall into two broad classes:

• Local recovery attempts fail: Using Settings → System → Recovery → Reset this PC will begin but then abort with a generic “There was a problem resetting your PC. No changes were made.” message or otherwise terminate without completing the refresh. The in‑place repair flow that uses Windows Update to reinstall the current OS also fails. (askwoody.com)
• Managed/remote wipes fail: Intune/Endpoint Manager administrators report RemoteWipe jobs that start remotely but fail partway through, leaving devices in a stuck or “unmanaged” state where the machine boots normally but the wipe did not complete successfully. Logs for these events frequently show servicing/packaging errors or missing payload symptoms. Independent writeups from field engineers tie many of these failures to servicing metadata issues introduced or changed by the August updates. (patchmypc.com, call4cloud.nl)

The practical impact is immediate and non‑trivial. Reset and repair flows are critical for:

• Recovering corrupted systems without full re‑install media
• Reprovisioning devices in Autopilot/OOBE scenarios when Autopilot fails
• Performing remote factory resets for lost/stolen or repurposed devices via management systems
• Repairing bricks caused by problematic updates or driver installs

When those pathways are unavailable, recovery becomes manual, longer, and riskier — often requiring bootable media, USB installation, or manufacturer recovery tools.

---

Why this looks serious (and how Microsoft is responding)​

This is not a localized device error: the failure mode shows up across different hardware vendors, multiple enterprise images, and in both consumer and managed environments. Microsoft acknowledged the problem publicly on its Windows release health channels and said it will ship an out‑of‑band update to resolve it before the next regular Patch Tuesday cycle. That escalation — an emergency OOB patch — reflects the severity and pervasiveness of the regression. (askwoody.com)
Key operational takeaways from Microsoft’s response:

• Status: Confirmed on Windows Release Health and treated as a known issue. (askwoody.com)
• Scope: Client OS only (Windows Server unaffected). (askwoody.com)
• Mitigation strategy: Microsoft is preparing an OOB update to be published via normal delivery mechanisms (Windows Update, Microsoft Update Catalog) before the next Patch Tuesday. Administrators should watch for the new KB and plan to deploy as soon as it’s available. (askwoody.com)

---

Technical analysis: what likely went wrong​

Publicly available incident reports from field engineers and update‑servicing analysts point to a pattern consistent with servicing metadata and component hydration mismatches introduced or altered by the update payloads. Two independent investigations are instructive:

• Analysis of failing remote wipe jobs shows the servicing engine referencing component packages (for example, UserExperience-AIX and UserExperience-Recall) that are registered as required in servicing metadata but whose payload files are incomplete or missing from WinSxS. When the reset/wipe process attempts to hydrate those components into WinRE or a fresh image, the operation fails and the reset aborts. This is tied to components introduced as part of new features/infra in recent cumulative updates. (patchmypc.com, call4cloud.nl)
• The problematic component names and symptoms map to new infrastructure for features such as Recall and other user‑experience additions that were being phased in across multiple branches. A missing DLL or incomplete package in the servicing folder can render the recovery tooling unable to reconstruct a clean image during reset. In one engineering debug thread, a missing zlib DLL inside a user experience package prevented hydration and blocked reset completion until the package metadata was removed or corrected. That manual metadata removal is risky and not recommended outside of recovery scenarios. (patchmypc.com, call4cloud.nl)

Put simply: the reset process depends on accurate servicing metadata and on having complete payloads available for component hydration. If the cumulative update leaves behind metadata that references files that are not present or not accessible in the expected WinSxS or servicing locations, reset and in‑place reinstall flows can and have failed.

Why the problem hits some images and not others​

Two reasons explain the uneven footprint:

• Image servicing method: Organizations that inject cumulative updates into offline WIMs or create custom images that had the update preapplied may have a mismatch between package metadata and actual payload files. On‑device servicing expects a consistent state that some offline‑image workflows break. (patchmypc.com)
• Partial payload hydration: If the servicing process (during image creation or update installation) fails to fully hydrate all WinSxS components, future reset operations which rely on those components will fail while other devices that completed hydration successfully will not be affected. (patchmypc.com)

---

Practical mitigations and recovery steps for admins and power users​

While awaiting Microsoft’s OOB update, administrators and support teams need practical, risk‑aware steps to limit customer pain and recover stuck devices.
Important: many of the fixes reported by community troubleshooters involve low‑level servicing metadata edits or deletions. Those actions can render updates or rollbacks unstable and are not recommended in normal circumstances. Use them only as a last resort and, if performed, do so with full backups and a recovery plan.
Short checklist — immediate actions

• Delay or block the August cumulative update in managed environments until Microsoft publishes the OOB fix, if you are on an affected branch. Use WSUS, the Windows Update for Business deferral controls, or your update orchestration tool to pause deployment.
• For devices already updated and showing reset/wipe failures, avoid repeated reset attempts that may partially modify system state. Collect logs first (Setup, CBS, and WindowsUpdateClient logs), then escalate to support.
• If remote wipe is required (e.g., lost/stolen device) and RemoteWipe fails, treat the machine as compromised and follow corporate data breach procedures — assume data is unrecoverable until a safe wipe path is available.

Recovery techniques that administrators have used successfully (ordered by least to most intrusive)

• Standard repair utilities and checks
• Run DISM and SFC to attempt to repair image corruption:
  dism /online /cleanup-image /restorehealth
  sfc /scannow
• Restart and retry Reset only after these complete. These commands can repair missing or corrupted OS files in many scenarios. (howtogeek.com)
• Reconfigure WinRE
• Reagentc /disable followed by reagentc /enable to refresh WinRE registration can resolve some failures when the recovery environment itself is misconfigured. This is safe and often recommended. (howtogeek.com)
• In‑place repair install (Windows Setup)
• Using an installation ISO to run an in‑place upgrade/repair reinstalls the current OS while preserving files and apps. This often bypasses Reset tooling entirely and can restore operability without a full wipe. (howtogeek.com)
• Bootable media factory reimage
• When reset fails and the device must be returned to a known state, a clean install from USB media is the last dependable option. This removes local data; ensure corporate backup and BitLocker recovery key procedures are observed. (prod.support.services.microsoft.com)
• Extreme/manual servicing metadata cleanup (dangerous)
• Multiple community posts documented success by removing or correcting corrupt servicing metadata entries in C:\Windows\servicing\Packages and/or deleting specific .mum/.cat entries. This can allow reset to complete but risks future update servicing. Only consider when device is otherwise unrecoverable and after discussing risk with stakeholders. (patchmypc.com, call4cloud.nl)

---

Guidance for enterprise admins: triage and policy guidance​

• Inventory and risk‑assess:
• Identify systems on the affected branches (23H2, 22H2, 22H2/22H2 LTSC SKUs listed above). Prioritize devices that rely on Reset/Autopilot/remote wipe for their lifecycle. (askwoody.com)
• Pause automatic deployment:
• If you manage updates via WSUS, SCCM/ConfigMgr, or Update Rings, hold the August updates from being applied to endpoints where reset/recovery is critical (e.g., frontline devices, kiosks, Autopilot devices). Use group targeting to prevent broad impact.
• Prepare support playbooks:
• Prewrite steps for support staff: how to collect logs (CBS, SetupAPI, WindowsUpdateClient), how to attempt DISM/SFC, the recommended safe approaches, and the escalation path to vendor support or Microsoft support with advisory IDs. (patchmypc.com)
• Watch for Microsoft’s OOB KB:
• Deploy the OOB update promptly in test rings; verify recovery flows after installation. The OOB will likely be delivered via Windows Update and Microsoft Update Catalog; monitoring those release channels and Windows Release Health announcements is essential. (askwoody.com)

---

Risk assessment and broader implications​

• Operational risk: This regression reduces the ability to recover and reprovision devices quickly. For IT shops that rely on Reset or Autopilot Reset for rapid recovery, the inability to perform these operations increases downtime and can require manual reimaging, creating extra costs and service desk load. (askwoody.com)
• Security risk: Failed remote wipe operations are particularly concerning for lost or stolen devices that need to be sanitized. When RemoteWipe fails, organizations should treat devices as potentially compromised and escalate accordingly. (call4cloud.nl)
• Reputational and trust risk: Regressions in recovery tooling shake confidence in update quality. When built‑in recovery features fail after a monthly update, both consumers and enterprise IT staff are likely to delay future updates — increasing the window of exposure to vulnerabilities. Microsoft’s rapid move to prepare an OOB patch helps, but patch quality and distribution trust will remain front‑of‑mind after incidents like this.
• Image creation and servicing workflows: The issue highlights the fragility of offline image servicing workflows that inject cumulative updates into WIMs. Organizations that maintain custom golden images must revalidate their build pipelines to ensure component hydration completes and WinSxS contents are consistent. (patchmypc.com)

---

What to watch for next (timeline and expectations)​

• Imminent OOB patch: Microsoft announced it will roll an out‑of‑band update for affected platforms in the coming days; administrators should monitor official Windows Release Health and Microsoft Update Catalog entries and plan a quick test & deploy cycle. (askwoody.com)
• Post‑fix validation: After applying the OOB update, validate Reset, Fix using Windows Update, and RemoteWipe flows across a small pilot group before widespread rollout. Confirm that both local and managed resets complete cleanly and that WinRE is healthy.
• Followup root cause analysis: Expect Microsoft to publish an incident note or update the Release Health entry with technical details explaining exactly which component packages or servicing metadata entries caused the failure. Until then, community investigations and independent writeups remain the best source of forensic detail available publicly. (patchmypc.com, call4cloud.nl)

---

Conclusion​

The August Patch Tuesday cumulative updates corrected many issues and delivered new features, but they also introduced a meaningful regression that prevents reset and recovery operations across several supported Windows client releases. The inability to rely on Reset this PC, in‑place repair via Windows Update, or remote wiping through management tools increases operational complexity and security risk for organizations and end users alike.
Microsoft’s rapid acknowledgement and commitment to an out‑of‑band fix is the correct immediate response, and administrators should prepare to:

• Pause broad deployments of the August updates on affected branches where feasible.
• Triage and remediate impacted devices using safe methods (DISM/SFC, WinRE re‑registration, or in‑place repair) where possible.
• Avoid dangerous servicing metadata edits except as last‑resort recovery techniques under controlled conditions.
• Test and deploy Microsoft’s OOB update quickly after it is released, then validate recovery scenarios before re‑opening wide deployment.

This incident is a clear reminder that recovery tooling is as important as security updates themselves; a fix that leaves devices unable to recover safely imposes cost and risk that can exceed the benefits of the update. The coming OOB release should be prioritized everywhere recovery functionality matters — and IT teams should add explicit recovery validation to their update test plans so that the next monthly roll cycle doesn’t deliver another unpleasant surprise. (askwoody.com, patchmypc.com, call4cloud.nl)

---

Source: Neowin Microsoft breaks reset and recovery options on older Windows versions