Microsoft has confirmed a serious regression in the August 2025 Patch Tuesday cumulative updates that breaks built-in reset and recovery functions across multiple still-supported Windows client versions. The company is preparing an out-of-band (OOB) emergency update to restore functionality, acknowledging the failure can block Reset this PC, the in-place repair option “Fix problems using Windows Update,” and remote wipe operations initiated through Intune or other management tools.

The problem, first flagged by IT administrators and community troubleshooters, stems from the August 12, 2025, security updates KB5063875 for Windows 11 versions 22H2 and 23H2, and KB5063709 for Windows 10 version 22H2 and various LTSC editions. After installing these updates, attempting a system reset from Settings → Recovery → Reset this PC often ends with a generic “There was a problem resetting your PC. No changes were made” message. The alternative repair method that uses Windows Update to reinstall the OS also fails, as do managed RemoteWipe jobs — leaving devices stuck in an indeterminate state.

Which Windows versions are affected?

Microsoft’s release health dashboard lists the affected client platforms:

  • 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

Notably, Windows Server SKUs and the newer Windows 11 version 24H2 are not impacted by this specific failure mode, providing a safe harbor for organizations that have already moved to the latest release.

What the failure looks like on the ground

The symptoms are consistent across hardware vendors and environments. IT pros report that local reset attempts begin but then abort without completing the refresh. Remote wipes initiated from Microsoft Intune or Endpoint Manager fail partway through, sometimes leaving the device in an “unmanaged” state where it boots normally but the wipe did not clean the device. Logs frequently show errors such as 0x800f0991, pointing to missing or mismatched servicing payloads.

Field engineers from Patch My PC and Call4Cloud have traced the root cause to servicing metadata introduced by the August updates. Their analyses show that the cumulative update leaves behind package references — for components like UserExperience-AIX and UserExperience-Recall — that are required for the reset process, but the actual payload files are incomplete or absent from the WinSxS store. When the reset engine tries to hydrate those components into the recovery environment or a fresh image, the operation fails and the entire reset aborts.

In one documented case, a missing zlib DLL inside a user experience package prevented hydration until the corrupt metadata was manually removed — a risky procedure not recommended outside of extreme recovery scenarios.

Why does it hit some machines and not others?

The uneven footprint can be explained by two factors. First, organizations that inject cumulative updates into offline WIM images or create custom deployment media may end up with a mismatch between package metadata and actual file payloads. On-device servicing expects a consistent state that some offline-image workflows inadvertently break. Second, even on devices updated online, the update installation process may not fully hydrate all WinSxS components, leaving future reset operations vulnerable. Devices that completed hydration successfully are unaffected.

Microsoft’s response: an out-of-band fix is on the way

Microsoft has publicly marked the issue as “Confirmed” on its Windows Release Health channels and stated that an out-of-band update will be released “in the coming days” — before the next regular Patch Tuesday. The emergency patch will be delivered through standard channels: Windows Update, Windows Update for Business, and the Microsoft Update Catalog. This rapid escalation from Redmond underscores the severity and pervasiveness of the regression.

Practical mitigations while you wait

Until the OOB fix lands, administrators and power users have a few safe options to reduce exposure and recover stuck devices:

  • Pause deployment: If you manage updates via WSUS, ConfigMgr, or Update Rings, block or defer KB5063875 and KB5063709 on affected client editions.
  • Standard repair utilities: Running DISM /online /cleanup-image /restorehealth followed by sfc /scannow can repair missing or corrupted system files in many cases. After completion, a retry of the reset may succeed.
  • Reconfigure the recovery environment: Use Reagentc /disable and then Reagentc /enable to refresh WinRE registration — a safe and often effective step.
  • In-place repair install: Using an installation ISO to perform an in-place upgrade reinstalls the OS while preserving files and apps, bypassing the broken reset tooling entirely.
  • Clean install from USB media: When a device must be returned to a known state and other methods fail, a full reimage remains the last dependable option.

Community reports also describe success with manually deleting offending .mum or .cat entries from C:\Windows\servicing\Packages. However, such edits can corrupt the servicing stack and break future updates. They should only be considered as a last resort, with full backups and a clear recovery plan in place.

Enterprise guidance: triage and policy

For IT administrators, the immediate priority is to protect recovery-critical workloads:

  1. Inventory affected devices: Identify all systems running the impacted OS builds, especially those that rely on Autopilot Reset, user-driven reset, or remote wipe.
  2. Pause automatic update deployment: Use group targeting to hold the August updates from frontline devices, kiosks, and any machine where a failed wipe or reset would cause significant business impact.
  3. Prepare support playbooks: Equip helpdesk staff with steps to collect diagnostic logs (CBS, SetupAPI, WindowsUpdateClient) and the recommended mitigation sequence — DISM/SFC, WinRE re-registration, in-place repair, and finally escalation if all else fails.
  4. Monitor for the OOB update: Once Microsoft publishes the emergency patch, test it quickly on a representative pilot group, validate that Reset, “Fix using Windows Update,” and RemoteWipe all complete successfully, then roll out broadly.

Broader implications and trust in update quality

This incident is not a minor hiccup. Reset and recovery pathways are critical for repairing corrupted systems, reprovisioning devices in Autopilot scenarios, and performing remote factory wipes for lost or repurposed hardware. When they break, recovery becomes manual, slower, and riskier — often requiring bootable media or manufacturer tools. For organizations managing hundreds or thousands of endpoints, the operational impact can be severe.

Failed remote wipes carry an additional security dimension: if a lost or stolen device cannot be sanitized, the organization must treat it as potentially compromised and follow data-breach procedures.

Beyond the immediate firefight, the regression chips away at the trust IT professionals place in monthly update cycles. When a routine Patch Tuesday breaks the very tools designed to fix problems, the natural reaction is to delay future updates — increasing the window of exposure to other vulnerabilities. Microsoft’s quick move toward an OOB patch is the correct response, but the industry will be watching to see how thoroughly the root cause is addressed and whether similar servicing metadata issues crop up in subsequent rollups.

The episode also highlights the fragility of offline image servicing. Organizations that maintain custom golden images must revalidate their build pipelines to ensure component hydration completes correctly and that WinSxS contents remain consistent after cumulative update injection.

What’s next

With the OOB update expected within days, the immediate focus is on validation. Once installed, administrators should explicitly test Reset, in-place repair, and RemoteWipe flows across a variety of hardware. The post-fix period will also likely bring a more detailed root-cause analysis from Microsoft, explaining exactly which component packages or metadata entries caused the failure. Until then, the independent investigations by Patch My PC and Call4Cloud remain the best publicly available forensic detail.

For now, the message is clear: if you manage Windows 10 22H2, Windows 11 22H2 or 23H2 clients, hold the August updates where recovery matters, prepare your support teams, and be ready to deploy the emergency fix the moment it lands. The coming days will be a stress test not only for Microsoft’s update mechanism, but for every IT shop’s ability to adapt quickly when the patches meant to protect them create a new set of problems.