Microsoft has quietly confirmed that the August 2025 Patch Tuesday rollup left a serious recovery hole: on several still‑supported Windows branches the built‑in Reset this PC and cloud recovery options can fail to complete, leaving devices unable to factory‑reset or perform dealer/IT wipe operations until Microsoft ships an out‑of‑band fix. (askwoody.com, theregister.com)
On August 12, 2025 Microsoft shipped the monthly security rollups for consumer and enterprise Windows channels. The packages included the cumulative updates that bring systems to new builds: notably KB5063878 for Windows 11 24H2 and KB5063875 for Windows 11 23H2/22H2, plus KB5063709 for Windows 10 22H2/21H2 and related LTSC SKUs. Microsoft’s standard cumulative update packaging (combined SSU + LCU) means these packages are delivered and installed automatically on most devices.
Within days of that rollout, reports from admins and end users surfaced describing two distinct but serious problems:
At the time this article is published, Microsoft was testing emergency patches for affected branches; independent outlets and community trackers reported the appearance of test packages in preview rings but the emergency KB (reported by some outlets as KB5066189) could not be located in the Microsoft Update Catalog or on the official KB listing at the time of reporting — that claim remains unverified until Microsoft publishes a confirmed KB entry. Readers should treat reports of a specific out‑of‑band KB number as provisional until Microsoft posts it to the Update Catalog. Flag: unverified.
Finally, some of the individual update pages for August’s rollups still display “Microsoft is not currently aware of any issues,” creating a confusing situation where the KB article content and the release‑health incident list are not synchronized. That mismatch matters because admins who check only an individual KB page may not see the release‑health incident and vice versa.
Microsoft’s recovery regressions this month are a reminder that the most sensitive parts of an operating system — the ones users invoke when things go wrong — need exceptional testing and communication. The fixes will come; in the meantime, protecting data and avoiding Reset workflows on affected builds are the simplest, safest actions an individual or IT team can take. (theregister.com, windowslatest.com)
Source: windowslatest.com Microsoft admits it broke "Reset this PC" in Windows 11 23H2 KB5063875, Windows 10 KB5063709
Background / Overview
On August 12, 2025 Microsoft shipped the monthly security rollups for consumer and enterprise Windows channels. The packages included the cumulative updates that bring systems to new builds: notably KB5063878 for Windows 11 24H2 and KB5063875 for Windows 11 23H2/22H2, plus KB5063709 for Windows 10 22H2/21H2 and related LTSC SKUs. Microsoft’s standard cumulative update packaging (combined SSU + LCU) means these packages are delivered and installed automatically on most devices. Within days of that rollout, reports from admins and end users surfaced describing two distinct but serious problems:
- On Windows 11 versions 23H2 and 22H2, and on affected Windows 10 SKUs, attempts to use Settings → System → Recovery → Reset this PC or the new Fix problems when using Windows Update cloud recovery flow simply fail and roll back the operation; the system reverts to the pre‑reset state with no successful reset performed. Remote wipe (RemoteWipe CSP) operations initiated by management tools can also fail.
- On Windows 11 24H2 the August update initially caused installation errors for some update channels (WSUS/SCCM), producing 0x80240069 in certain enterprise deployments; and separately there are isolated reports — concentrated in Japan — of storage devices (SSDs/HDDs) becoming inaccessible after the August update. Microsoft’s public KB pages for some of these updates listed no known issues at the time they were posted, producing a confusing and inconsistent picture for admins. (bleepingcomputer.com, pcworld.com)
Which versions and updates are affected
Short list — the immediate impact
- Windows 11, version 23H2 (cumulative KB5063875 / build 22631.5768 or 22621.5768 variants).
- Windows 11, version 22H2 (also covered by KB5063875 on some SKUs).
- Windows 10, version 22H2 and certain LTSC/IoT LTE SKUs (KB5063709 and related packages).
- Remote wipe (Intune / CSP) operations that call into the same recovery code paths are affected on those client branches. (askwoody.com, support.microsoft.com)
Not affected (at least initially)
- Windows 11, version 24H2 was reported as not impacted by the Reset/Recovery failure mode; however, 24H2 customers are seeing other issues (install errors via WSUS/SCCM and isolated storage failures in some regions). Microsoft’s KB pages for KB5063878 initially stated there were no known issues — a statement that created a mismatch between the release notes and the release‑health incident entries published elsewhere. (support.microsoft.com, bleepingcomputer.com)
What exactly is failing — technical anatomy
Reset, cloud recovery and remote wipe operations all rely on a common set of mechanisms inside Windows:- A Windows Recovery Environment (WinRE) or a cloud-based reinstallation path that rebuilds the OS image, optionally preserving user data.
- Service and driver configuration inside the WinRE environment so storage controllers and encryption (BitLocker) drivers actually function during the reset.
- Management APIs and Configuration Service Providers (CSPs) that trigger a local or remote reset/wipe.
Why this matters — risks and operational impact
- Home users expecting to pass a machine on or perform a factory reset before sale risk being unable to wipe their device safely using the built‑in Reset flow. That increases the likelihood of improper data sanitization or accidental retention of personal data.
- Enterprises & managed fleets face a larger exposure: remote wipe and Autopilot/Intune reset workflows are standard operating procedures for offboarding or reprovisioning. If a wipe fails silently, devices might leave the environment still containing corporate data or remain attached to an old tenant. This is a compliance and security risk.
- Support overhead will spike. Help desks will see cases where a reset — the usual first‑line remedy for a flaky device — no longer works. That forces manual reimage procedures (external media, technician intervention) and lengthens Mean Time To Repair.
- False sense of safety. Windows does not warn users before invoking the reset that the reset path is known to be unreliable on affected builds. Users therefore proceed in good faith and encounter a failed reset only after their device reboots and reports “no changes were made.” That mismatch between expectation and reality is a quality and transparency failure.
- Data loss edge cases. While the primary reports indicate resets roll back without deleting user files, any time recovery code misbehaves there is a non‑zero risk of partial operations leaving a system in an inconsistent state. The community has seen similar reset/wipe regressions historically that left devices unbootable or required manual recovery. Backups are therefore essential.
What Microsoft has said and done so far
Microsoft’s release‑health/known‑issue tracking and support teams acknowledged the problem: the incident entries and community trackers mark the Reset/Recovery failure as “confirmed” for the affected platforms, and Microsoft has promised to release an out‑of‑band update to correct the regression in the coming days. Multiple outlets reporting on the incident quote Redmond’s confirmation that “attempts to reset or recover the device might fail.” (askwoody.com, theregister.com)At the time this article is published, Microsoft was testing emergency patches for affected branches; independent outlets and community trackers reported the appearance of test packages in preview rings but the emergency KB (reported by some outlets as KB5066189) could not be located in the Microsoft Update Catalog or on the official KB listing at the time of reporting — that claim remains unverified until Microsoft publishes a confirmed KB entry. Readers should treat reports of a specific out‑of‑band KB number as provisional until Microsoft posts it to the Update Catalog. Flag: unverified.
Finally, some of the individual update pages for August’s rollups still display “Microsoft is not currently aware of any issues,” creating a confusing situation where the KB article content and the release‑health incident list are not synchronized. That mismatch matters because admins who check only an individual KB page may not see the release‑health incident and vice versa.
Community and third‑party confirmation
Coverage from multiple independent publications, sysadmin forums and telemetry from enterprise admins corroborated the problem and documented the same symptoms: resets aborting, remote wipe commands failing to complete, and in some cases large numbers of helpdesk tickets. Reports also surfaced that Windows 11 24H2 installs were failing in WSUS/SCCM and that a small cluster of storage failures (mostly in Japan) may be linked to the updates — these are separate but concurrent incidents that add to administrative pain. (windowslatest.com, pcworld.com)Practical guidance — immediate actions for users and admins
Below is a prioritized checklist: follow the items in the order they appear, adapting them to your environment.For home users and small businesses
- Avoid using Settings → System → Recovery → Reset this PC on machines running Windows 11 23H2/22H2 or Windows 10 22H2/21H2 until Microsoft issues the out‑of‑band fix. If you absolutely must wipe a device prior to transfer of ownership, use bootable installation media to perform a clean install instead.
- Back up important data now. Use an external drive, cloud backup (OneDrive/other), or disk image tool (Macrium, Acronis, Veeam Endpoint Backup). Do not rely on the built‑in Reset to preserve or sanitize data. Historical incidents show resets can behave unpredictably.
- Create a recovery USB stick (Media Creation Tool). If you later need to do a full reinstall, having official installation media saves time and reduces risk. Steps: download Microsoft’s Media Creation Tool (or the ISO) and write to an 8GB+ USB. Boot from that device to clean install or access Windows recovery options.
- Check whether the August update is installed. Open Settings → Windows Update → Update history or run PowerShell: Get‑HotFix | Where‑Object {$_.HotFixID -match "KB50637" } to see KBs (or use wmic qfe). If you are on an affected build and you don’t plan to reset, you can continue to use the machine — the vulnerability fixes in the rollup are important — but avoid invoking Reset.
- If a reset fails already: do not retry blindly. Boot to external media and use the installer’s repair or clean install option. If BitLocker is enabled, ensure you have the recovery key before taking recovery steps.
For enterprise and IT administrators
- Pause mass reset/wipe operations. Do not send device wipe or Autopilot Reset commands to fleets on affected branches until Microsoft releases the out‑of‑band patch and you validate it in a pilot ring. Unreliable wipes will generate helpdesk churn and could leave devices in an unusable or noncompliant state.
- Test in a controlled ring. If you must apply the August rollups, stage them in a pilot pool and validate remote wipe and recovery flows (Intune Autopilot Reset, RemoteWipe CSP, local Reset) before deployment to the general population.
- Prepare recovery media and offline reimaging plans. Design and test your reimaging/playbook for devices that will not respond to remote wipe. Ensure technicians have bootable USB images built with current drivers and onboarded Autopilot provisioning images where appropriate.
- Inventory BitLocker keys and management. If a recovery path fails and devices enter BitLocker recovery, you need access to keys. Verify key escrow in your M365/Entra tenant and make sure helpdesk staff know where to retrieve keys.
- If updates cause WSUS/SCCM install errors (24H2 0x80240069), follow Microsoft’s interim guidance (where applicable) and track the release‑health dashboard for the WSUS fix; some vendors reported temporary WSUS workarounds but those are advanced and should be tested.
How to check if your device is on an affected build (quick steps)
- Open Start → Run, type winver, press Enter. Note the OS build and version string.
- Or open Settings → System → About to view the OS Build and version.
- In PowerShell (Admin): run (Get‑ComputerInfo).OsBuild or Get‑HotFix to enumerate installed KBs.
- Consult the Microsoft KB pages for the August rollups (KB5063878 for 24H2, KB5063875 for 23H2/22H2, KB5063709 for Windows 10) to match build numbers. If your build matches the published August build numbers, assume you may be affected.
Uninstallation and rollback: caveats and realities
Many cumulative updates are shipped as combined SSU + LCU packages. Microsoft specifically notes that a combined package may not be removable via the Windows Update Standalone Installer (wusa.exe /uninstall) because the servicing stack update is included. For stubborn cases, Microsoft suggests DISM with Remove‑Package using the exact LCU package name; however, doing so is advanced, can leave the servicing stack in an inconsistent state if done improperly, and is not recommended for average users. That leaves two practical recovery options:- Use System Restore if a restore point exists from before the update.
- Use bootable installation media (clean install) to reinstall Windows and restore user data from backups.
Analysis: what likely went wrong and where Microsoft stumbled
- The symptoms strongly suggest a regression inside the WinRE / Recovery subsystems rather than a hardware or driver change. Reset and RemoteWipe share code paths and rely on the WinRE image and Safe OS dynamic updates; a small change in how the recovery image is serviced or invoked can break those flows. Previous incidents (WinRE updates with insufficient recovery partition space, incorrect error codes, and storage driver mismatches) demonstrate how fragile the interactions can be between servicing updates and the recovery environment.
- Microsoft’s release cadence (combined SSU+LCU monthly rollups) reduces the number of update artifacts but increases the blast radius when something regresses, because a single monthly package touches many subsystems. When recovery code paths are modified, the change can affect home and enterprise scenarios differently, and QA often misses corner cases (e.g., particular combinations of OEM recovery partition layouts, bitlocker states, or custom driver sets). The apparent discrepancy between individual KB articles (saying no known issues) and the release‑health incident entries (confirming the reset failure) also indicates a procedural gap in how Microsoft synchronizes public documentation and incident reporting. (support.microsoft.com, askwoody.com)
- The 24H2 WSUS install error (0x80240069) and the localized SSD reports in Japan are separate but compounding problems: they show that multiple failure modes can emerge from a single monthly release window, placing extra pressure on support teams and making it easier for admins to miss the specific recovery regression. (bleepingcomputer.com, pcworld.com)
Strengths and positives (what Microsoft did right)
- Microsoft acknowledged the problem publicly and listed it in release‑health / incident pages, which is a critical transparency step for admins monitoring those dashboards. They also committed to an out‑of‑band fix, which, when deployed quickly, reduces the long tail of operational pain.
- Microsoft’s commitment to combined SSU+LCU packages generally reduces update fragmentation, and in normal months this approach simplifies patch management for many organizations.
- Several outlets and admin communities quickly documented tests and workarounds, giving admin teams interim options while the patch was prepared.
Weaknesses and risks (what Microsoft needs to fix)
- The documentation mismatch (KB pages listing no known issues while release health tracked a confirmed incident) is an unacceptable friction point for admins who rely on authoritative KBs for update triage. Microsoft must ensure consistency between KB entries and release health status in real time.
- The recovery subsystem is a high‑risk component that demands additional regression testing across OEM images, encrypted drives (BitLocker), and management scenarios (Intune/Autopilot). The recurring pattern of recovery and reset regressions suggests that Microsoft should expand regression test coverage and strengthen pilot ring gating for recovery code changes.
- The lack of a clear, Microsoft‑published interim workaround for resets (beyond “don’t run reset”) leaves less experienced users exposed. A clear Microsoft KB with explicit instructions and safe alternatives should be mandatory during such incidents.
Long‑term considerations for organizations
- Treat Windows reset as an emergency recovery tool, not a primary provisioning or reimaging mechanism. For reliable fleet workflows, maintain bootable provisioning media, golden images and automated rebuild procedures that do not depend solely on the in‑place Reset flows.
- Strengthen backup and key escrow practices. Store BitLocker keys in Entra ID / M365 and make sure helpdesk staff know how to retrieve them quickly.
- Expand lab testing to include real OEM recovery partitions, disk encryption, and common vendor drivers; do not rely on clean lab installs as the only validation path.
Closing / Recommendations (concise checklist)
- If you are running Windows 11 23H2/22H2 or Windows 10 22H2/21H2, do not attempt Reset this PC or cloud recovery until Microsoft’s out‑of‑band patch is released and validated.
- Back up important data immediately and prepare external installation media for manual reimage/repair.
- IT teams: freeze remote wipe/reset workflows, validate in a pilot ring, and prepare reimaging playbooks with verified ISOs and drivers.
- Watch Microsoft’s release‑health dashboard and official Update Catalog entries for the confirmed emergency fix; treat any reports of a specific KB number (e.g., KB5066189) as unverified until the Update Catalog or Microsoft publishes an official KB article. Flag: unverified until Microsoft publishes.
- When the emergency patch arrives, deploy it first to pilot systems and validate reset/wipe operations before broad rollout.
Microsoft’s recovery regressions this month are a reminder that the most sensitive parts of an operating system — the ones users invoke when things go wrong — need exceptional testing and communication. The fixes will come; in the meantime, protecting data and avoiding Reset workflows on affected builds are the simplest, safest actions an individual or IT team can take. (theregister.com, windowslatest.com)
Source: windowslatest.com Microsoft admits it broke "Reset this PC" in Windows 11 23H2 KB5063875, Windows 10 KB5063709
