August 2025 Patch Tuesday: Reset Regression, SSD Storage Issue, and OOB Fix

Microsoft’s August Patch Tuesday has gone from a routine security maintenance window to an operational headache for administrators and home users alike, as the August 12, 2025 rollups introduced a pair of serious regressions — first a storage regression that could make some SSDs disappear under heavy writes, and then a separate bug that broke built‑in Reset and recovery workflows — forcing Redmond to ship emergency out‑of‑band updates to repair the damage.

Background and overview​

Microsoft shipped its August 2025 cumulative security updates on August 12. These combined servicing stack updates (SSU) and latest cumulative updates (LCU) were intended to patch a large set of security issues, including a zero‑day, while delivering routine quality fixes. Within days, however, community testing and telemetry surfaced two high‑impact problems: a storage regression tied to the Windows 11 24H2 cumulative (notably KB5063878) that could make some NVMe SSDs stop responding during sustained large writes, and a separate regression originating in client rollups (for example KB5063875 and KB5063709) that caused Reset my PC, the cloud Fix problems using Windows Update flow and RemoteWipe CSP operations to fail.
Microsoft publicly acknowledged the reset/recovery regression on its Release Health pages and issued an out‑of‑band (OOB) remediation the following week — publishing non‑security OOB packages (for example KB5066189 for Windows 11 23H2/22H2 and companion KBs for affected Windows 10/LTSC branches) to correct the regression. At the same time, vendors and researchers continued to investigate the SSD disappearances and recommended cautious behavior while Microsoft and hardware partners completed telemetry analysis.

---

What actually broke: technical symptoms and triggers​

Reset and recovery regression — what fails and when​

The reset/recovery regression manifests when a user or management system attempts one of the following flows:

• Settings → System → Recovery → Reset this PC (both keep my files and remove everything flows are implicated).
• Settings → System → Recovery → Fix problems using Windows Update (the cloud recovery / in‑place reinstall path).
• RemoteWipe CSP invoked by MDM solutions (the remote wipe/reset path used by Intune/Endpoint Manager).

On impacted systems the workflow may start, trigger one or more reboots, and then abort with a rollback and a message such as “No changes were made,” or fail silently and return the desktop unmodified. For remote wipes, management consoles reported jobs that started but did not complete, leaving devices in inconsistent states. Microsoft’s Release Health entry describes the issue succinctly and identifies the originating August KBs that introduced the regression.

Storage regression — drives that vanish under heavy writes​

Independently, and distinct from the reset/regression, community testers reproduced a storage fault tied to heavy sequential writes on certain SSDs after installing KB5063878 (Windows 11 24H2). Typical triggers were sustained transfers on the order of ~50 GB or more and controller utilization above ~60%. Symptoms include the target NVMe SSD disappearing from File Explorer, Device Manager, and Disk Management mid‑write, unreadable SMART/controller telemetry, and, in a minority of reports, persistent device inaccessibility requiring vendor intervention. Early test matrices implicated multiple controllers and vendors, although Phison‑based controllers were frequently referenced in early reports. Microsoft and SSD vendors engaged to investigate.

---

Timeline — how events unfolded​

• August 12, 2025 — Microsoft publishes the August Patch Tuesday cumulative updates (LCU + SSU) for multiple client branches, including KB5063878 (Windows 11 24H2), KB5063875 (Windows 11 23H2/22H2 variants), and KB5063709 (Windows 10 22H2/LTSC). Initial KB release notes focused on security fixes and quality changes.
• Within days — community researchers and vendors report two clusters of problems: (a) storage devices disappearing during heavy writes on systems with KB5063878, and (b) reset and cloud recovery attempts failing on systems with client‑KBs such as KB5063875 and KB5063709. Reports and reproducible tests appear on enthusiast sites and forums.
• August 18–19, 2025 — Microsoft posts a Release Health advisory confirming the reset/recovery regression and labels it “Confirmed,” advising affected customers to avoid using the implicated recovery flows until a fix is available. Microsoft prepares and releases out‑of‑band remediation packages.
• August 19, 2025 — Microsoft publishes OOB updates (for example KB5066189 for Windows 11 23H2/22H2 and sibling KBs for affected Windows 10/LTSC branches) to address the reset/recovery regression and recommends that customers who haven’t installed August's security rollups yet install the OOB update instead. Independent outlets report the OOB release and urge admins to apply the fix.
• Ongoing — Microsoft and SSD vendors continue investigating the storage regression; incident pages and vendor advisories are updated as telemetry and firmware patches become available. Administrators are left to balance patching urgency against operational risk.

---

Which Windows versions and KBs were affected​

• Reset/recovery regression: identified in client rollups associated with August cumulative updates for Windows 11 23H2/22H2 and multiple Windows 10 branches. The Microsoft advisory explicitly calls out the originating August KBs (such as KB5063875 and KB5063709) and points to the OOB packages that fix the issue.
• Storage regression: most often tied to KB5063878 for Windows 11 24H2 (OS Build 26100.4946) but reports vary by region and model. Community labs and vendor statements indicate the problem is workload‑specific and hardware‑dependent.

Notably, Windows Server SKUs were not listed in Microsoft’s reset/recovery advisory as impacted, and Windows 11 version 24H2 initially appeared exempt from the reset/recovery regression — though 24H2 had its own isolated storage headaches. That split highlights how slightly different update packages and servicing stacks can produce divergent outcomes across the Windows family.

---

Why this is more than an annoyance: practical risks for IT and users​

A broken Reset this PC or failed remote wipe is not a mere UX bug — it strips administrators and users of last‑resort recovery and sanitization tools.

• Data protection risk: users attempting to recover a device may trigger a reset that aborts, leaving the machine in an inconsistent state and exposing partially applied changes or corrupted profiles.
• Operational cost: help desks and IT operations may be forced into manual rebuilds, image re‑deployments, or onsite intervention for devices that could otherwise be restored or re‑provisioned remotely.
• Security and compliance worry: Remote wipe failures impede rapid response to lost or compromised endpoints and complicate decommissioning workflows that are required for regulatory compliance in many sectors.
• Data loss potential (storage regression): although the storage regression appears workload‑limited, files being written at the time of a device disappearance are at risk of corruption, and a minority of reports describe devices that remain inaccessible even after reboots. This elevates the incident from an inconvenience to a potential data‑loss event for affected users.

Together, these faults show how a monthly update — even one focused on security — can have cascading effects across device lifecycle tools and hardware interactions.

---

Microsoft’s response and the out‑of‑band fix​

Microsoft’s Release Health and KB documentation confirm the reset/recovery regression and identify OOB remediation packages. The vendor released KB5066189 for Windows 11 23H2/22H2 on August 19, 2025, describing it as a non‑security, optional out‑of‑band quality update that addresses the issue and corrects WinRE/recovery code paths. Companion OOB KBs were published for the Windows 10 and LTSC branches affected by the August rollups. Microsoft recommended that organizations who had not yet installed the August security rollups apply the OOB update instead.
Independent reporting confirmed Microsoft’s advisory and the availability of the emergency updates, urging immediate deployment for devices that rely on the broken recovery flows. Administrators reporting successful remediation noted that installing the OOB package restored Reset and remote wipe behavior on previously affected machines.
Caveat: while the reset/recovery regression was addressed rapidly, the storage regression remained under investigation at the time of the OOB rollouts — requiring vendor firmware updates and further telemetry correlation before a full, definitive root cause and universal remediation were published.

---

What administrators and power users must do now​

The incident underscores the need for pragmatic, prioritized responses. The following steps are a distilled playbook for IT teams and experienced users:

• Inventory and triage
• Identify devices in your fleet that received the August 12, 2025 updates (check KB installation history via WSUS, SCCM, Microsoft Intune, or Settings → Windows Update → Update history).
• Flag machines running Windows 11 23H2/22H2, Windows 10 22H2 and LTSC variants as potentially impacted for reset/recovery regression.
• Apply the out‑of‑band updates where appropriate
• For affected client branches, deploy the OOB KBs (for example KB5066189 on Windows 11 23H2/22H2 and the corresponding KB5066188/K5066187 packages for Windows 10/LTSC). Microsoft recommends installing the OOB update in lieu of the original August rollup for devices that haven’t yet been patched.
• Use staged deployment (pilot → phased roll‑out) and monitor results before fleet‑wide install.
• Protect data and avoid risky workloads
• Until vendor guidance is clear for the SSD storage regression, avoid sustained large sequential writes and large game or archive installations on recently patched machines with suspect SSD models. Back up data immediately.
• Prepare manual recovery options
• Ensure you have bootable media, system images, and known‑good recovery media available if remote reset or cloud recovery paths are unreliable.
• Update incident runbooks to route devices that fail reset/wipe into manual remediation queues.
• Watch vendor advisories and telemetry
• Track Microsoft Release Health, SSD vendor advisories, and community reproducibility matrices; prioritize firmware updates from vendors only after backups and validation.

---

Deeper analysis: how and why this happened​

Several structural realities combine to make incidents like this plausible.

• Complexity of cumulative updates: modern LCUs bundle many fixes, and the combined delivery of SSU + LCU changes multiple servicing and boot‑time code paths. A regression in WinRE/servicing stack code can therefore surface only when recovery flows are executed — a comparatively rare but critical path. That makes pre‑release testing for every possible recovery scenario challenging at scale.
• Hardware diversity and hidden dependencies: SSD firmware and controller behavior increasingly depends on nuanced host‑side interactions (HMB, DMA timing, kernel buffering). Small changes in host behavior can expose latent firmware bugs on particular controller/factory‑firmware combinations. Community reproduction across many device models highlighted that the storage regression was not strictly limited to a single branded SKU but correlated with workload patterns and controller characteristics.
• Telemetry and signal detection lags: telemetry that triggers automatic mitigations relies on correctly attributed signals. When multiple symptoms appear close together (storage regressions vs. reset failures), distinguishing root causes becomes slower and public messaging can lag, increasing confusion for admins.

Microsoft’s fast turnaround on the reset/recovery OOB shows a functioning incident response process; the fact that two separate regressions emerged within days, however, highlights the fragility of a global update pipeline and the challenge of ensuring zero‑regression in recovery and hardware compatibility code paths.

---

Strengths and weaknesses of Microsoft’s handling​

Notable strengths​

• Rapid confirmation and public advisory: Microsoft posted Release Health guidance and acknowledged the reset/recovery issue quickly after community reports coalesced.
• Out‑of‑band remediation: issuing OOB KBs (KB5066189 and siblings) within days demonstrates an ability to release targeted fixes outside the normal monthly cadence when warranted.
• Coordination with vendors: SSD vendors and Microsoft engaged on the storage regression, accelerating telemetry sharing during a volatile period.

Notable weaknesses and risks​

• Inconsistent messaging across KB pages: some public KB entries initially listed “no known issues,” while Release Health entries reflected confirmed customer impact — a mismatch that caused confusion among administrators.
• Update packaging complexity: combined SSU + LCU packages make rollbacks and removals harder for administrators and can complicate mitigations in managed environments.
• Ongoing hardware risk: the storage regression required deeper vendor firmware work and could not be fully mitigated by a single OOB Windows update in all cases, leaving some users exposed to data integrity risk until vendors released firmware fixes.

---

Longer‑term lessons for IT teams and Microsoft​

• Stage updates and pilot widely: enterprises must treat even “security” monthly rollups as operational events and continue to enforce staged rollout policies, pilot testing, and rapid rollback/runbook procedures.
• Expand recovery testing: both Microsoft and OEMs should include more exhaustive automated tests of recovery flows (Reset, WinRE paths, RemoteWipe) under a variety of storage configurations and stress conditions to catch regressions earlier.
• Improve telemetry and communication: clearer, consolidated messaging across KB pages and Release Health would reduce confusion. When emergent issues are confirmed, Microsoft should proactively flag affected KBs and provide explicit remediation guidance and timeline estimates.
• Vendor/OS co‑testing: increased collaboration and shared test harnesses between Microsoft and SSD controller vendors could prevent other hardware/firmware interactions from being exposed by host updates.

---

Practical checklist — immediate actions for admins (concise)​

• Apply OOB updates (KB5066189, KB5066188, KB5066187) to affected branches where reset/recovery operations are required.
• If you haven’t installed August updates yet, consider installing the OOB package instead of the original August LCU.
• Back up critical data now and avoid heavy sequential writes on recently patched systems until SSD vendor guidance is clear.
• Stage deployments and monitor pilot groups closely for both reset/recovery behavior and storage anomalies.
• Maintain up‑to‑date firmware for SSDs as vendor firmware updates become available and validate on test machines before broad rollout.

---

Conclusion​

The August 2025 update incident is a sharp reminder that modern OS servicing is a systems problem: a monthly security rollup can touch servicing components, recovery environments, storage paths and management interfaces all at once. Microsoft’s rapid acknowledgment and out‑of‑band fixes for the reset/recovery regression mitigated a critical failure mode, but the parallel storage regression exposed the limits of pre‑release testing across the vast diversity of hardware and workload patterns in the real world. For administrators and power users the practical takeaways are straightforward and urgent: prioritize backups, stage updates, apply the emergency OOB packages where recovery is required, and treat firmware updates and vendor advisories with the same caution as OS patches. The episode should sharpen everyone’s posture on testing, telemetry, and the need for clearer, unified communication when incidents hit production systems.

---

Source: IT Pro Microsoft’s botched August update batch first wiped SSDs, now it’s breaking PC resets and recoveries on Windows