Microsoft has confirmed an emergency out‑of‑band (OOB) Windows update after August’s Patch Tuesday rollup caused built‑in recovery tools — Reset this PC, the cloud reimage flow Fix problems using Windows Update, and MDM‑initiated RemoteWipe CSP — to fail on multiple client branches, and independent reporting shows a concurrent, separate problem: a storage anomaly causing some SSDs to disappear or present as RAW during heavy writes. The vendor pushed targeted OOB packages on August 19, 2025 to restore recovery functionality, while the SSD reports remain under investigation and require cautious handling by users and IT teams. (support.microsoft.com) (bleepingcomputer.com)
Background
Microsoft’s normal August Patch Tuesday cumulative updates were published on August 12, 2025 and included multiple LCUs and SSUs across Windows client servicing families. In the days after that rollup, field telemetry and community reports surfaced describing two distinct operational failures.- The immediate, confirmed regression prevented Windows’ own recovery flows from completing on affected devices: local resets would start but abort and roll back with messages such as “No changes were made,” cloud reimage flows would fail to finish, and some MDM‑initiated remote wipes would not complete. Microsoft acknowledged the regression and classified it as a known issue. (bleepingcomputer.com)
- Separately, reports emerged that a different August cumulative (notably KB5063878 on the Windows 11 24H2 branch) could trigger SSD devices to disappear under heavy write workloads or show partitions as RAW, potentially causing data corruption for a subset of drives. This storage issue has been the subject of community testing and vendor scrutiny but remains under active investigation by Microsoft and SSD controller vendors. Early analyses point to interactions between heavy sequential writes and certain SSD controllers, rather than a single app or game being the root cause. (tomshardware.com, techradar.com)
What Microsoft confirmed (the facts)
The recovery regression: scope and remediation
Microsoft’s official OOB update notes and Release Health entries make the core facts clear: after installing specific August security updates, attempts to reset or recover the device might fail. The vendor identified the originating August KBs and published corresponding optional OOB fixes on August 19, 2025:- Affected originating updates: KB5063875 (Windows 11 23H2 / 22H2), KB5063709 (Windows 10 22H2 / LTSC 2021 variants), KB5063877 (Windows 10 Enterprise LTSC 2019 variants). (bleepingcomputer.com)
- Out‑of‑band fixes published August 19, 2025: KB5066189 for Windows 11 23H2/22H2 (OS Builds 22621.5771 / 22631.5771), KB5066188 for Windows 10 servicing families (OS Builds 19044.6218 / 19045.6218), and KB5066187 for Windows 10 Enterprise LTSC 2019 (OS Build 17763.7683). Each OOB package is distributed as a combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) where applicable and supersedes the earlier August rollup for the affected branch. (support.microsoft.com, windowslatest.com)
The SSD reports: confirmed investigation, not a full recall
Microsoft publicly acknowledged that it is investigating reports of SSDs failing or becoming inaccessible after August updates. Multiple independent outlets and community testers found reproducible conditions where heavy, large‑file writes (for example, the distribution of a large game patch) could cause some SSDs to vanish from the OS and BIOS or present the partition table as RAW. Vendor participation—most notably controller vendors like Phison—began as affected vendors analyzed the telemetry. At the time Microsoft shipped the OOB recovery fixes, the storage anomaly remained an active investigation rather than a confirmed, universal bug tied to a single KB. (tomshardware.com, techradar.com)Technical anatomy: why the recovery flows failed
How Reset, cloud recovery and RemoteWipe interlock
Reset‑and‑recovery flows are orchestrated across several components:- Windows user interface and Settings orchestration for initiating Reset this PC.
- The Windows Recovery Environment (WinRE) stages and applies the new image or reset payload.
- The Servicing Stack and update metadata that stage required packages and control sequencing.
- Cloud recovery flows which may download an image, update WinRE, and trigger an in‑place reinstall.
- RemoteWipe CSP which leverages MDM commands and the same underlying servicing logic to sanitize or reprovision devices.
Likely failure modes
Community logs and vendor writeups pointed to these likely failure classes:- Package sequencing mismatch: the LCU/SSU ordering may have left WinRE or recovery payloads in an unexpected state.
- Servicing stack edge cases: updated SSU logic may have introduced behavioral changes that fail under certain path checks.
- Environment variance: OEM disk encryption, third‑party drivers, or unusual firmware/UEFI combinations can surface regressions that did not appear in lab testing.
The SSD problem explained (what we know and what we don’t)
Symptoms reported by testers and users
Independent testing documented symptoms such as:- Large sequential write operations (often >20–50GB, and more likely on nearly full drives) triggering temporary disappearance of a drive from File Explorer and sometimes even from BIOS/UEFI.
- In some cases the partition table showed as RAW and devices required reboot or vendor tools to recover; a minority of devices in following tests were unrecoverable without vendor intervention. (tomshardware.com, windowscentral.com)
Which drives appear affected
Early reports clustered around drives using certain controllers (notably Phison) and DRAM‑less designs, but tests later showed problems across multiple brands and controller types. Researchers emphasized the issue appears workload‑triggered (heavy, sustained writes) and environment‑sensitive (drive free space, firmware revision, and motherboard/BIOS interactions). This makes a single blanket mitigation impractical; instead, cautionary avoidance of heavy writes on recently patched machines and thorough testing in lab rings are recommended. (tomshardware.com, techradar.com)Investigation status and vendor involvement
Phison and other storage vendors opened investigations with industry partners and Microsoft. At the moment of writing, Microsoft had not published an OOB fix specifically for the storage anomaly; instead, the company confirmed it was investigating the reports and coordinating with partners. Users with critical data are advised to avoid heavy writes until vendors provide confirmed mitigations or firmware updates. This remains an ongoing situation. (tomshardware.com, techradar.com)Practical, prioritized actions for home users and IT teams
Immediate steps (for all users)
- Back up critical data now — follow the 3‑2‑1 backup rule: three copies, on two different media, one off‑site.
- If you have already experienced an attempted Reset that failed, install the OOB update for your branch immediately (KB5066189 for Windows 11 23H2/22H2; KB5066188/KB5066187 for Windows 10 families). These OOBs supersede August’s rollup and include SSU components. (support.microsoft.com)
- If you have not installed the August 12, 2025 rollup yet, install the OOB package appropriate for your servicing branch instead of the original August rollup. (support.microsoft.com)
Storage‑specific caution (until vendors confirm fixes)
- Avoid large sequential writes (for example, large game patches or multi‑GB installers) on systems that installed recent August security updates, particularly on systems with SSDs that are older, near capacity, DRAM‑less, or based on controllers that community testing has implicated. (tomshardware.com, windowscentral.com)
- If you must handle big transfers, do so after verifying vendor advisories and ensuring you have a recent full disk backup or image.
- If an SSD becomes inaccessible or shows RAW after a large write, stop further disk operations and reboot to see if the device reappears; consult vendor recovery tools and support. Avoid repeated writes that could risk overwriting recoverable data.
For IT administrators and MSPs (prioritized checklist)
- Inventory: determine which devices applied August rollups (KB5063875, KB5063709, KB5063877, KB5063878, etc.). Use management tools to enumerate installed KBs.
- Pilot and validate: install the OOB packages in a staged ring, validate Reset this PC and cloud recovery flows, and test MDM RemoteWipe end‑to‑end on representative hardware.
- Hold reset/wipe automation: pause automated reprovisioning or scheduled remote wipes for devices that likely have the August rollup until OOBs are validated.
- Update firmware and vendor software: coordinate with SSD/OEM vendors on firmware updates and test any vendor mitigation before deployment. (tomshardware.com)
- Communicate: inform help desks and field staff about the possibility of failed Reset operations and SSD anomalies; provide fallback remediation steps (bootable media, image restore, vendor tools).
Why this matters: operational and trust implications
The two incidents together illustrate the systemic fragility and complexity of modern OS servicing:- Recovery paths are mission‑critical. Reset and cloud recovery are last‑resort tools for both home users and enterprises. When they fail, manual reimaging skyrockets mean time to repair (MTTR) and creates compliance and security gaps for organizations that rely on remote sanitization. Microsoft’s rapid OOB response reduced exposure, but the initial regression left many organizations scrambling. (bleepingcomputer.com)
- Hardware interactions can magnify risk. The SSD anomaly highlights how host OS changes can interact with a broad variety of storage controller firmware and hardware states. Exhaustive pre‑release testing across the diversity of real‑world hardware remains impractical, making staged rollouts and pilot rings essential. (tomshardware.com)
- Communications and documentation matter. Early inconsistencies between KB pages and Release Health notices created confusion for administrators. Clear, consolidated advisories — including explicit lists of affected KBs and recommended remediation steps — are vital during incidents.
Critical analysis: strengths, weaknesses and latent risks
Microsoft’s strengths in this incident
- Rapid detection and remediation: Microsoft publicly acknowledged the reset regression and shipped targeted OOB updates within a week, opting for surgical fixes (SSU+LCU) rather than waiting for the next Patch Tuesday window. That move reduced the exposure time for high‑impact recovery failures. (support.microsoft.com, bleepingcomputer.com)
- Correct technical approach: bundling a servicing stack refresh with the LCU addresses sequencing and update reliability at the correct layer for reset/recovery regressions. (support.microsoft.com)
Where Microsoft and the ecosystem can improve
- Pre‑release coverage gaps: the regressions and storage anomalies expose how limited lab testing is against the combinatorial explosion of OEM firmware, SSD controller behavior, and real‑world workloads. Expanded co‑testing with OEMs and controller vendors would reduce surprises.
- Messaging consistency: initial KB pages and release notes lagged or conflicted with Release Health advisories, increasing triage time for admins. Better synchronization between product pages and incident advisories would help.
Latent risks to watch
- Partial recovery visibility: although OOBs restore reset flows in many cases, complex fleet mixes still risk edge cases where automation assumes successful resets (for example, autopilot or device reprovisioning pipelines). Administrators should not assume a full return to normalcy until pilots validate automation end‑to‑end.
- Storage firmware lag: even after vendor firmware fixes appear, the patching cadence for SSD firmware is uneven. Organizations relying on consumer SSDs in fleets should prioritize hardware refresh or vendor‑certified models for critical endpoints. (tomshardware.com)
Recommended longer‑term actions (policy and process)
- Maintain an enforced pilot ring and accelerated rollback runbook for monthly security rollups. Treat each cumulative update as an operational event, not a routine background task.
- Expand telemetry around recovery flows (WinRE failures, RemoteWipe logs) to detect regressions within 24–48 hours of mass rollouts.
- Increase vendor co‑testing: establish formal test harnesses with SSD controller vendors and OEMs to run heavy write and recovery scenarios that mirror real‑world game patches, large installers, and update staging.
- Harden backup posture: ensure image‑based restore capability and frequent verification; do not rely on Reset this PC as the single fallback.
Conclusion
The August 2025 incident is a reminder that modern operating‑system servicing sits at the intersection of software, firmware, and hardware diversity. Microsoft’s swift OOB updates fixed a high‑impact regression that broke Reset and cloud recovery flows for many Windows users; administrators and power users should install the matching OOB packages (KB5066189 / KB5066188 / KB5066187) if they experienced failures or plan to use recovery features. At the same time, the separate reports of SSD disappearances under heavy writes are an active investigation involving SSD controller vendors and require conservative handling: back up data, avoid large writes on recently patched machines, and wait for vendor guidance or firmware fixes before broad deployments. These events underscore the practical need for staged rollouts, robust backups, vendor coordination, and clearer communications — the operational disciplines that make modern update stewardship resilient. (support.microsoft.com, tomshardware.com)Source: Forbes Microsoft Confirms Emergency Windows Update—Your PC ‘Might Fail’