Microsoft shipped urgent out-of-band (OOB) updates on August 19, 2025, after its August Patch Tuesday cumulative rollups caused built-in Windows recovery tools—Reset this PC, cloud reimage, and MDM RemoteWipe—to fail on multiple client branches. The vendor also confirmed it is investigating separate reports that another August security update, KB5063878, can trigger SSDs to disappear or present as RAW under heavy write workloads, a storage anomaly that remains unresolved and demands caution from users and IT admins alike.

The Recovery Regression: What Broke and How It Was Fixed

On August 12, 2025, Microsoft released its routine Patch Tuesday updates for Windows 11 23H2/22H2 (KB5063875), Windows 10 22H2 and LTSC 2021 (KB5063709), and Windows 10 Enterprise LTSC 2019 (KB5063877). Within days, field telemetry and community forums lit up with complaints that attempts to reset a PC, run a cloud recovery, or trigger a remote wipe via MDM would abort with messages like “No changes were made,” leaving devices in an unrecoverable state without manual reimaging.

Microsoft quickly classified the behavior as a known issue and published targeted OOB fixes just one week later. The three packages—KB5066189 for Windows 11 (builds 22621.5771/22631.5771), KB5066188 for Windows 10 22H2 and LTSC 2021 (builds 19044.6218/19045.6218), and KB5066187 for Windows 10 Enterprise LTSC 2019 (build 17763.7683)—combine an updated servicing stack (SSU) with a latest cumulative update (LCU) to supersede the faulty August rollups. Microsoft’s guidance is clear: if you experienced a failed reset or plan to use recovery features, install the OOB package for your branch immediately; if you haven’t yet installed the August security updates, deploy the OOB instead of the original rollup.

How Recovery Flows Collapsed

Recovery operations depend on a delicate orchestration between the Windows Recovery Environment (WinRE), the servicing stack, and various update packages. When the August LCUs changed package sequencing or servicing metadata in ways not fully exercised across all hardware and firmware combinations, the reset path would fail and the system would intentionally roll back to protect integrity. Likely failure modes included package sequencing mismatches, servicing stack edge cases, and environmental variances—OEM encryption, third-party drivers, or atypical UEFI settings. The OOB fixes addressed these by refreshing the servicing stack and correcting the cumulative packaging, restoring the expected WinRE behavior.

The SSD Anomaly: A Separate and Unresolved Danger

While the recovery regression was confirmed and patched, a second problem emerged independently. Users and testers noticed that after installing KB5063878 (Windows 11 24H2) or the earlier KB5062660, certain solid-state drives would vanish during heavy, sustained write operations—typically large game patches or file transfers exceeding 50 GB when the drive was more than 60% full. In some cases, the drive reappeared after a reboot; in rarer instances, the partition table showed as RAW and was unrecoverable without vendor tools.

A systematic test by community researcher @Necoru_cat on X tested 21 drives by copying a 50+ GB Steam library folder, creating a compressed archive, and then writing the expanded archive to the target SSD. Twelve of the drives became inaccessible during the test. Most returned after a reboot, but a Western Digital SA510 2TB failed permanently. The results spanned multiple controller types, including DRAM-less designs, and implicated a workload-triggered interaction rather than a single brand.

Controller maker Phison issued a statement to Tom’s Hardware acknowledging that its controllers might be among those affected and said it was working with industry stakeholders on remediation. Microsoft confirmed it is investigating but has not released an OOB fix for the storage issue. The root cause appears tied to how Windows handles cache flushing or command queuing under extreme write pressure, possibly in conjunction with specific firmware behaviors. Until patches or firmware updates materialize, the only mitigation is to avoid heavy sequential writes on systems that have taken the August security updates.

What You Should Do Right Now

For all Windows users

  • Back up critical data immediately. Follow the 3-2-1 rule: three copies, on two different media, one off-site.
  • If you have experienced a failed Reset or plan to use recovery features, install the OOB package for your branch: KB5066189 (Windows 11 23H2/22H2), KB5066188 (Windows 10 22H2/LTSC 2021), or KB5066187 (Windows 10 Enterprise LTSC 2019). These supersede the faulty August rollups.
  • If you have not yet installed the August 12 updates, deploy the OOB directly instead of the original KBs.

For the ongoing SSD risk

  • Suspend large sequential write operations (game updates, multi-GB file copies) on machines that received KB5063878 or KB5062660, particularly if the SSD is older, near capacity, or DRAM-less.
  • If a drive disappears or shows RAW, stop disk activity immediately, reboot, and check if the device reappears. Use vendor-provided recovery tools; avoid repeated writes that could overwrite recoverable data.
  • Monitor vendor communications from Microsoft, Phison, and your SSD manufacturer for firmware updates or specific mitigations.

For IT administrators and MSPs

  • Inventory affected devices: identify all endpoints that installed KB5063875, KB5063709, KB5063877, KB5063878, or KB5062660.
  • Stage the OOB recovery fixes in a pilot ring and validate Reset, cloud recovery, and RemoteWipe on representative hardware before broad deployment.
  • Pause automated reprovisioning or remote wipe schedules until the OOBs are validated.
  • Update SSD firmware in coordination with OEM vendors and test any vendor-supplied fixes.
  • Prepare fallback reimaging media (USB recovery drives, deployment images) to avoid reliance on the built-in reset tools in the interim.

Why This Matters

The twin incidents expose the fragility of modern OS servicing, where a single cumulative update can break the very tools designed to repair the system. Reset and cloud recovery are last-resort mechanisms for home users and enterprises alike; when they fail, manual reimaging skyrockets mean time to repair and creates security and compliance gaps. The storage anomaly further demonstrates that host OS changes can cascade into hardware-specific failures, highlighting the impossibility of exhaustive lab testing against every real-world firmware and workload combination. Microsoft’s rapid OOB response on the recovery front limited damage, but the continuing SSD investigation underscores the need for staged rollouts, vendor co-testing, and always-current backups.

The Road Ahead

Microsoft’s handling of the recovery regression—acknowledgment within days and surgical OOB packages—was commendably swift. Yet the SSD reports reveal a persistent blind spot: interactions between Windows updates and storage controllers remain under-tested. As the industry awaits a formal fix for the drive-disappearance bug, the episode reinforces a few timeless disciplines: treat every Patch Tuesday as an operational event, never skip the pilot ring, and never trust a single fallback recovery path. For now, applying the OOB updates will restore reset functionality, but the safest course for any system that has already taken the August security rollups is to pause heavy writes and wait for clear vendor guidance before returning to normal workloads.