Microsoft shipped out-of-band cumulative updates on August 19, 2025, to fix a critical bug that broke Windows’ built-in Reset, cloud re-image, and remote wipe features after the August Patch Tuesday rollups. The emergency update comes as a separate wave of user reports—still under investigation by Microsoft and SSD vendors—describes NVMe drives disappearing or turning RAW under heavy write workloads on systems running those same August patches.

What Broke: The Reset and Recovery Regression

After installing the August 12 security updates, many users and IT administrators discovered that several core recovery functions were silently broken. On affected systems, initiating “Reset this PC” (either “Keep my files” or “Remove everything”), using the cloud re-image option under “Fix problems using Windows Update,” or triggering a RemoteWipe through MDM would start the process, boot into Windows RE, and then abort with a generic “No changes were made” message, leaving the system untouched.

Microsoft correlated the failure to a servicing stack regression in the August originating rollups for multiple client branches:
- Windows 11 versions 23H2 and 22H2 – KB5063875 (August 12 cumulative update)
- Windows 10 22H2 and select LTSC/IoT LTSC SKUs – KB5063709 and sibling packages

The company acknowledged the issue on its Release Health dashboard and in dedicated KB articles, recommending users avoid the affected recovery tools until a fix was available. For enterprise admins, the stakes were immediate: broken RemoteWipe meant that compromised or decommissioned devices could not be securely sanitized through normal MDM channels, disrupting zero-trust and lifecycle policies.

Emergency OOB Fixes Arrive

On August 19, Microsoft released targeted out-of-band (OOB) updates designed to undeploy the regression. These optional, non-security cumulative packages combine a Latest Cumulative Update (LCU) with a Servicing Stack Update (SSU), ensuring the fix is self-contained and doesn’t require prior updates. The key packages include:

  • KB5066189 – Windows 11 (OS Builds 22621.5771 and 22631.5771) for 23H2/22H2
  • KB5066188 – Windows 10 22H2 / LTSC 2021
  • KB5066187 – Windows 10 Enterprise LTSC 2019 / IoT LTSC 2019

The OOB updates are available through Windows Update as optional downloads and can also be obtained from the Microsoft Update Catalog for manual deployment or WSUS integration. Microsoft explicitly states that these packages address the Reset, cloud re-image, and RemoteWipe failures, and recommends installation for any system that experienced the regression. For devices not impacted or that will not use those recovery flows, the OOB is optional. However, many IT professionals are treating it as a required patch to preempt any unexpected recovery needs.

Administrators should note the SSU/LCU combination means the servicing stack cannot be uninstalled separately once applied. Microsoft provides DISM commands to remove the LCU component if necessary, but warns the SSU remains persistent—a factor that complicates rollback planning in tightly managed environments.

SSD Anomalies: Disappearing Drives and RAW Partitions

While the recovery regression was being diagnosed, a parallel set of reports surfaced on community forums and from independent testers: certain NVMe SSDs were vanishing from the operating system or suddenly appearing as RAW (unformatted) after sustained large writes. The triggers were commonly described as continuous write workloads exceeding roughly 50 GB—for example, large game installs, full-disk cloning, or extracting massive archives—on systems running the August 12 cumulative updates.

The problem was not universal; it clustered around specific drive models, notably some using Phison controllers and other vendors’ silicon. Enthusiast testers and vendor telemetry both pointed to a pattern: drives near capacity or those relying on DRAM-less architectures seemed most vulnerable. In mild cases, the SSD would disappear mid-transfer and reappear after a reboot, with in-flight data possibly corrupted but the drive otherwise functional. In severe instances, the drive remained inaccessible, lost partition metadata, or mounted as RAW, requiring vendor recovery tools, firmware reflash, or even a full RMA. In such scenarios, uninstalling the Windows update did not restore the corrupted data because the damage occurred on the SSD media itself, not just in the host OS.

Phison, a controller vendor frequently cited in reproductions, confirmed it was investigating along with Microsoft and other partners. Microsoft likewise acknowledged the storage reports and stated it was coordinating with hardware vendors. However, at the time of writing, no definitive root cause or list of affected models has been published by Microsoft or the SSD makers. The evidence so far points to a device-dependent interaction between the August patches and certain NVMe controller/firmware combinations under heavy I/O stress.

What’s Confirmed, What’s Provisional

  • Confirmed: Microsoft publicly documented the Reset/Recovery regression and issued OOB fixes (KB5066189, KB5066188, KB5066187). The symptoms and mapping to the August originating KBs (KB5063875, KB5063709, etc.) are well-established.
  • Confirmed: Widespread community reports and vendor engagement corroborate the SSD anomalies, but no single root cause has been released. Treat storage failure claims as hardware-specific and provisional until vendors publish precise firmware or compatibility findings.
  • Not supported: Claims of universal or permanent SSD destruction caused solely by the update. The data shows a pattern of workload-induced errors on certain devices, not a blanket failure.

Immediate Actions for Users and Administrators

Data Protection First

  • Back up immediately. Follow the 3-2-1 rule: three copies of critical data, on two different types of media, with one copy off-site. Perform full disk images on any SSD that will be subjected to heavy writes or recovery attempts.
  • Avoid large sequential writes on systems still running the August 12 patches until vendor firmware updates or official guidance is released. This includes game installs, disk cloning, and bulk extraction.

Installing the Fix

  • If you’ve already experienced Reset failures, install the appropriate OOB for your branch (e.g., KB5066189 for Windows 11 23H2/22H2). The OOB supersedes the buggy August cumulative and restores recovery functionality.
  • If you haven’t installed August updates yet, consider skipping the original rollups and deploying the OOB directly. Microsoft recommends this path when the recovery regression is a concern.

Enterprise Deployment

  • Inventory affected systems: Identify machines that received the August 12 updates (KB5063875, KB5063709, etc.).
  • Pilot the OOB fixes: Deploy to a representative sample of hardware and validate Reset, cloud re-image, and RemoteWipe operations before broad rollout.
  • Pause automated reprovisioning that relies on Reset or RemoteWipe until testing confirms the OOB works in your environment.

If an SSD Disappears Mid-Write

  1. Stop all write activity to the drive immediately to avoid further damage.
  2. Reboot once; if the drive reappears, capture SMART data and vendor logs.
  3. If the drive stays offline, try to image the raw device using dd or the manufacturer’s tool. Do not reformat if data recovery is a priority.
  4. Contact the SSD vendor for guidance and potential RMA.

Microsoft’s Incident Response: The Good and the Gaps

Strengths:
- Speed: The OOB packages arrived within a week of the confirmed regression, proving Microsoft can operate outside its monthly cadence for high-impact incidents.
- Multi-channel remediation: In addition to OOB updates, Known Issue Rollback was used for certain WSUS delivery snags, and vendor partnerships were activated for the storage investigation.

Weaknesses:
- Poor in-product communication: The Reset UI and recovery prompts gave no warning that the operation might fail. Most users learn of the bug only after a failed attempt, by which time they may already be in a problematic state.
- Combined package complexity: Bundling the SSU with the LCU simplifies deployment but makes rollback harder, as the SSU cannot be uninstalled. This forces admins into more rigid update management.
- Hardware coverage gaps: The SSD incident highlights the near-impossibility of testing every NVMe controller/firmware combo, but it also underscores the need for deeper co-testing with storage vendors before pushing changes that affect the I/O stack.

A Look Under the Hood: What Likely Caused the Regressions

Recovery failure: The pattern points to a servicing stack metadata corruption that caused WinRE flows to abort. The fact that the OOB includes an SSU supports this theory: a defect in how the August SSU/LCU combination handled recovery environment pathways. Microsoft’s engineering post-mortem, if released, will be key to understanding the exact mechanism.

SSD dropouts: The consistent trigger of sustained large writes—often on drives near capacity or with DRAM-less controllers—suggests subtle changes in OS buffering or write scheduling exposed latent firmware bugs. When the host suddenly alters the pattern of NVMe commands, controllers with insufficient power-loss protection or flawed wear-leveling logic can panic and drop off the bus. This is typical of firmware corner cases that were already present but never hit with earlier Windows builds. Vendor firmware updates, rather than Windows patches, will likely be the permanent fix.

Lessons for the Future

  • Hardware-software integration testing must expand: Microsoft and SSD controller vendors should maintain shared test harnesses that exercise real-world write workloads before cumulative updates ship.
  • Critical feature regression testing requires depth: Recovery flows are mission-critical; they deserve the same QA rigor as boot and update processes, including diverse storage configurations.
  • User-facing advisories must meet users where they are: When a known issue breaks a core system action, the OS should gate that action with a clear warning, not rely on a web-only KB article.
  • Enterprise update rings are non-negotiable: Organizations that run pilot rings and validate reprovisioning workflows would have caught the Reset failure before mass deployment. This incident reinforces that practice.

What to Watch For Coming Weeks

  • Vendor firmware bulletins: The definitive list of affected SSD models and corresponding firmware fixes will come from drive makers, not Microsoft.
  • Microsoft’s transparency: A detailed post-mortem—explaining why the August patches broke recovery and what QA changes will be made—would go a long way toward rebuilding confidence.
  • Extended testing of August OOB: As the OOB packages soak, admins should watch for any side effects, especially on storage I/O, given the parallel SSD investigation.

The August 2025 Patch Tuesday will be remembered not for its security payload but for the collateral damage it caused to two pillars of system reliability: recovery and storage. Microsoft’s emergency OOB update (KB5066189 and siblings) restores the ability to reset and re-image Windows machines—a crucial fix for anyone caught in a boot-loop or provisioning dead end. The SSD anomalies, however, remain an open wound, with data loss a real possibility for unlucky users. Until hardware vendors publish firmware updates and Microsoft clarifies the root cause, the watchwords are backup, caution, and patience. Apply the OOB fix if you need recovery tools; hold off large writes on potentially affected drives; and keep a close eye on vendor bulletins. In an ecosystem as diverse as Windows, the only true safety net is a well-executed backup strategy—never more so than when the update meant to protect your system inadvertently becomes a threat.