• Thread Author
Microsoft pushed emergency out‑of‑band updates on August 19, 2025, to repair a critical regression that prevented Windows’ built‑in reset and recovery tools from completing — a problem introduced by the August 12, 2025 Patch Tuesday security rollup that caused attempted “Reset this PC” and cloud recovery operations to start, reboot, and then immediately roll back without finishing.

A desktop computer on a desk displays a blue security screen with a shield icon.Background​

The August 2025 cumulative security updates were deployed through the regular monthly channel on August 12, 2025. Within days, Microsoft’s release‑health advisories acknowledged a serious regression: after installing specific August security KBs, attempts to run System > Recovery > Reset my PC, use the Fix problems using Windows Update cloud recovery option, or perform certain remote wipe operations could fail. The company confirmed the issue applied across a range of client builds and issued targeted, optional out‑of‑band (OOB) cumulative updates on August 19, 2025 to correct the failure.
This story matters because reset and recovery features are core tools for both consumers and IT administrators. When these tools break, routine remediation — from troubleshooting a badly behaving app to preparing a device for reuse — becomes riskier, slower, and in the worst cases requires a full manual reinstall.

What went wrong: symptoms and user experience​

How the failure presented​

  • Users initiating Reset this PC or the Fix problems using Windows Update cloud recovery option saw the process begin normally.
  • The device rebooted to continue the reset or recovery sequence as expected.
  • Instead of progressing to completion, the system immediately initiated a rollback and returned to the previous pre‑reset state, leaving the user no closer to a repaired or fresh system.
  • In some enterprise scenarios, RemoteWipe CSP‑driven resets also failed, impacting remote management workflows.
This behavior effectively neutralized the most convenient built‑in self‑repair path in affected builds. For many home users and frontline IT help desks, that meant resorting to USB media, network-based reinstalls, or time-consuming manual recovery steps.

Error signatures and variability​

The public disclosures noted the broad symptom of reset/recovery failure rather than one single error code present on all affected machines. Some earlier, related update failures (from the same August rollup family) had produced specific installer errors such as 0x8007007F when upgrades or installs were attempted from certain delivery channels; the reset/recovery regression, however, was characterized primarily by the reboot‑then‑rollback loop during reset operations. Where users encountered additional, specific error codes or log entries, those details were variable and environment‑dependent.

Affected platforms and update identifiers​

Microsoft’s communications and the subsequent OOB releases identify the following problematic August 2025 security updates and the corresponding affected platforms:
  • KB5063875 — Windows 11 (versions 23H2 and 22H2).
  • KB5063709 — Windows 10 (version 22H2) and Windows 10 Enterprise LTSC 2021 / Windows 10 IoT Enterprise LTSC 2021.
  • KB5063877Windows 10 Enterprise LTSC 2019 and Windows 10 IoT Enterprise LTSC 2019.
Microsoft released the following OOB cumulative fixes on August 19, 2025 to address the regression:
  • KB5066189 — Windows 11, versions 23H2/22H2 (OS Builds 22621.5771 and 22631.5771).
  • KB5066188 — Windows 10, version 22H2 and LTSC 2021 (OS Builds 19044.6218 and 19045.6218).
  • KB5066187 — Windows 10 Enterprise LTSC 2019 / IoT Enterprise LTSC 2019 (OS Build 17763.7683).
Two important technical notes about these OOB releases:
  • The OOB updates are cumulative; they supersede the earlier August rollups for the affected versions, so administrators and users do not have to apply prior updates before installing the OOB package.
  • Microsoft made the OOB updates optional but recommended that systems which have not yet received the August security rollup install the OOB version instead to avoid inheriting the reset regression.

Microsoft’s emergency response: timeline and mechanics​

Microsoft’s timeline in brief:
  • August 12, 2025 — Standard Patch Tuesday security rollups published (including KB5063875 / KB5063709 / KB5063877 among others).
  • Early reports and telemetry showed failures in reset/recovery operations after deployment.
  • August 15–19, 2025 — Microsoft investigated, confirmed the regression in release health notes, and developed fixes.
  • August 19, 2025 — Non‑security out‑of‑band updates (KB5066189 / KB5066188 / KB5066187) released to address the regression.
By issuing non‑security OOB cumulative updates rather than waiting for the next Patch Tuesday cycle, Microsoft followed a faster remediation route appropriate for a bug that blocks fundamental recovery tooling. The OOB approach meant the fixes were packaged as combined servicing stack + LCU packages in some builds; administrators should be aware of servicing stack requirements documented alongside each KB (some OOB packages included updated SSUs as part of the release).

Why this matters for consumers and enterprises​

Consumer impact​

  • For home users, Reset this PC is a primary troubleshooting option when Windows becomes unstable, apps misbehave, or malware has altered system behavior. When the reset path fails, the fallback is often a manual reinstall from USB or cloud recovery, which is slower and more complex.
  • Users who discovered the problem mid‑reset risked interruption, anxiety, and lost time — especially those who expected a straightforward process.

Enterprise and managed environments​

  • Enterprise fleets that rely on remote management and device lifecycle actions — for example, RemoteWipe CSP, kiosk resets, or automated remediation policies — can face operational disruption if resets fail across many endpoints.
  • Long‑term servicing channels such as LTSC editions are commonly used in regulated or mission‑critical environments where in‑place repair workflows are essential. A regression in reset functionality thus carried outsized operational risk for those administrators.
  • IT teams that defer updates until organizational testing is complete benefited from cautious patching; organizations that deployed the August security rollups broadly and immediately were most exposed.

How to get the fix: practical guidance​

The OOB updates were distributed through Microsoft’s standard channels; steps for individual users and IT admins differ slightly.

For individual users​

  • Open Settings > Windows Update.
  • Select Check for updates.
  • If an Optional updates available link appears, follow it and look for the appropriate KB5066189 (Windows 11) or KB5066188/KB5066187 (Windows 10/ LTSC) based on your OS build.
  • Install the cumulative OOB update and reboot when prompted.
  • After the update, attempt Reset this PC or your recovery action again.
If the optional OOB update does not appear in Windows Update, users can obtain the package from the Microsoft Update Catalog or use in‑place repair media as a fallback (create a Windows installation USB and run an in‑place upgrade/repair that preserves files and apps).

For IT administrators​

  • Use Windows Update for Business, WSUS, or Microsoft Endpoint Configuration Manager to approve and deploy the specific OOB KB that matches the targeted OS builds.
  • Verify servicing stack prerequisites documented in the KB article; some OOBs included a combined SSU/LCU and may require particular SSU baselines for reliable installation.
  • Test the OOB in a pilot ring before widespread deployment to confirm it resolves the reset regression in your environment while not introducing new issues.
  • For devices that were not yet updated to the August rollups, prefer deploying the OOB package instead of the original August LCU to avoid the regression entirely.

Recovery options when Reset already failed​

If "Reset this PC" has already failed and the OOB update is not available or does not resolve the condition, administrators and technically confident users can follow these recovery options:
  • Boot from a Windows installation USB and perform an in‑place upgrade/repair that keeps files and applications; this often repairs component store corruption and restores recovery paths.
  • Use Windows installation media to perform a clean install if backups exist and data preservation is not required.
  • Use system image backups or third‑party disk imaging to recover a known good image.
  • Run offline repair tools: boot to WinRE and use DISM /Image: and SFC /scannow against the offline image to attempt component repair.
  • For enterprise devices with management tooling, coordinate a remote reimaging via PXE/MDT/Intune autopilot re-provisioning workflows.
Note: These steps carry varying degrees of risk and complexity. Always ensure data is backed up before attempting in‑place repair or reinstall operations.

Security trade‑offs: to patch now or wait?​

The situation presented a classic trade‑off between security and reliability:
  • The August 12 LCU contained security fixes that organizations might not want to delay, especially for internet‑facing endpoints or systems processing sensitive data.
  • The August 19 OOB fixes are non‑security cumulative patches that replace earlier LCUs for the affected builds. Installing the OOB instead of the problematic August LCU avoids the reset regression while delivering the same security fixes for those versions.
  • For administrators who had not yet deployed August updates, the correct guidance was to apply the OOB packages rather than the initial August rollups. For those who already installed the original August rollups, installing the OOB will supersede them and restore reset/recovery behavior.
Delaying security updates for the sake of functionality is rarely a net win; in this case, Microsoft’s OOB fixes provided a path to both security and functionality — albeit requiring administrators to alter standard monthly deployment plans.

Root cause and process critique​

Microsoft’s public notes described the regression as introduced by the August 2025 security updates. The company’s deployment of OOB cumulative updates indicates the fix was implemented at the servicing/LCU level rather than a mere configuration toggle.
Key process and governance observations:
  • The regression highlights the complexity of modern OS servicing: patches touch many subsystems and an innocuous change can surface in disparate areas such as reset components and cloud recovery workflows.
  • The speed of Microsoft’s response — identifying the regression, acknowledging it via release health, and shipping OOB fixes within a week — demonstrated an operationally mature incident response cadence. Rapid OOBs reduce exposure time.
  • However, the incident reinforces the necessity for robust pre‑release testing across the full diversity of builds and OEM images. LTSC, IoT, and consumer images differ and can expose corner cases.
  • For organizations, the event underscores the importance of staggered deployment and pilot rings; rolling updates to a small fraction of the fleet before broad rollout remains best practice.

Best practices for admins and power users​

  • Implement ringed deployments. Maintain a pilot and phased rollout process, and hold back critical operations devices until a pilot has validated the update.
  • Monitor release health and advisories. Check vendor release health portals immediately after large monthly updates are published.
  • Automate backups and image capture. Keep recent system images or VHD snapshots so devices can be restored quickly in a regression event.
  • Use out‑of‑band packages when provided. If a vendor releases a cumulative OOB fix that supersedes a problematic rollup, prefer the OOB for new deployments.
  • Test recovery workflows. Regularly validate Reset, Repair, and In‑Place Upgrade flows in corporate images; automated runbooks can verify end‑to‑end function.
  • Document remediation procedures. Keep a ready checklist for recovery when reset/recovery fails (media creation, DISM/SFC steps, in‑place upgrade instructions).

Potential risks and outstanding uncertainties​

  • Although the OOB updates were broadly described as resolving the reset/recovery issue, variations in custom OEM images, Secure Boot/UEFI configurations, and firmware differences mean that edge cases remain possible. Administrators should validate on a representative sample of hardware before mass deployment.
  • Some reports of unrelated update side effects — for example, update install failures on certain storage hardware in other KBs from the same month — were circulating at the time; those claims require independent verification in each environment and should be treated cautiously until confirmed by vendor telemetry or official advisories.
  • The reset/regression fix itself was not a security update; organizations must still ensure they are applying necessary security patches for other vulnerable components in a timely manner.
Any claim of “no known issues” after an out‑of‑band release should be treated pragmatically: absence of new reported problems does not guarantee zero impact across every hardware and software configuration.

Practical checklist: immediate actions for IT teams​

  • Inventory systems to determine which devices received the August 12, 2025 rollups (KB5063875, KB5063709, KB5063877).
  • For devices that have not yet received August updates: plan to deploy the August 19 OOB KBs instead of the earlier August rollups.
  • For devices that received the August 12 updates and are experiencing reset/recovery failures: apply the matching August 19 OOB package, then re‑test recovery flows.
  • If OOB application fails or the reset problem persists: follow recovery options (in‑place repair via installation media, restore from image).
  • Update internal runbooks and notify help desk staff of the correct remediation steps to reduce user escalation times.

Broader takeaways for Windows lifecycle and update strategy​

This incident is a reminder that modern OS servicing is a balance between security velocity and operational stability. Critical recovery features are mission‑critical for end‑users and IT teams alike; when those features are affected, the operational cost can rapidly exceed the cost of the original security defect.
  • Maintain a disciplined update cadence: pilot → staged → broad.
  • Prioritize verification of recovery and provisioning paths in update validation matrices.
  • Keep communication channels open and documented so end users and desk teams can respond consistently when regressions occur.

Conclusion​

The August 2025 Patch Tuesday rollups introduced a high‑impact regression in Windows’ reset and recovery paths that Microsoft addressed with targeted out‑of‑band cumulative updates on August 19, 2025. The fixes restore the functionality of Reset this PC, the cloud recovery tool, and RemoteWipe‑driven resets for the affected builds. The incident demonstrates both the fragility and the resilience of enterprise software servicing: regressions can cause widespread pain, but a rapid vendor response and cumulative OOB updates can mitigate risk effectively if administrators act deliberately and test before broad deployment. Organizations should apply the OOB packages for unpatched systems, deploy the fixes into pilot rings first, and maintain robust backup and imaging practices so that recovery remains possible even when built‑in tools stumble.

Source: Новини Live Microsoft pushes critical out-of-band update for Windows recovery bug
 

Back
Top