Windows August 2025: OOB Fixes Restore Recovery, SSD Anomalies

Microsoft has quietly acknowledged a serious disruption in core Windows recovery flows and pushed emergency, out‑of‑band (OOB) updates after the August 2025 Patch Tuesday rollups left some systems unable to complete “Reset this PC,” cloud re‑image operations, and certain remote wipe jobs — and, separately, community testing and vendor telemetry raised alarms that an August cumulative may destabilize some SSDs during large, sustained writes. (support.microsoft.com) (bleepingcomputer.com) (windowscentral.com)

Background / Overview​

Microsoft shipped its regular August monthly cumulative updates on August 12, 2025. Within days, users, IT administrators, and independent testers reported two distinct but potentially related failure modes: (1) a regression that prevented Reset and other recovery flows from finishing on affected Windows client branches, and (2) storage anomalies in which some SSDs reportedly vanished from the OS or presented as RAW after heavy write workloads on systems running the August 12 packages. (support.microsoft.com)
Both problems attracted rapid community attention because they strike at essential elements of system reliability: recovery flows are the last line for fixing or re‑provisioning devices, and storage corruption or device disappearance risks irreversible data loss. Microsoft acknowledged the recovery regression and released targeted OOB fixes on August 19, 2025; the storage reports remain under active investigation with vendors and researchers collaborating on telemetry and reproduction. (bleepingcomputer.com)

---

What broke: Reset, cloud re‑image and RemoteWipe failures​

Symptoms and scope​

After installing the August security rollups, some users found that initiating:

• Settings → System → Recovery → Reset this PC (both “Keep my files” and “Remove everything”),
• System Recovery → Fix problems using Windows Update (cloud reimage),
• RemoteWipe CSP (MDM‑initiated remote reset/wipe),

would start normally, reboot into WinRE, and then abort with messages like “No changes were made,” leaving the machine unchanged. This behavior was reproducible in a range of community reports and enterprise telemetry and was explicitly described by Microsoft on its Release Health / KB pages. (support.microsoft.com) (bleepingcomputer.com)

Affected builds and originating KBs​

Microsoft and independent reporting tied the reset/regression to the August originating rollups for several client servicing branches, most notably:

• Windows 11 versions 23H2 and 22H2 — KB5063875 (August 12, 2025 rollup),
• Windows 10 22H2 and select LTSC/IoT LTSC SKUs — KB5063709 and related August KBs.

Microsoft’s remediation guidance and the OOB packages map directly to these originating KBs. (support.microsoft.com)

---

Microsoft’s emergency response: Out‑of‑band fixes (KB5066189 and siblings)​

What Microsoft released​

On August 19, 2025 Microsoft published optional, non‑security out‑of‑band cumulative updates that bundle a Latest Cumulative Update (LCU) and a Servicing Stack Update (SSU) to repair the regression. Notable packages include:

• KB5066189 — Windows 11 (OS Builds 22621.5771 and 22631.5771) for 23H2/22H2. (support.microsoft.com)
• KB5066188 — Windows 10 22H2 / LTSC 2021 families.
• KB5066187 — Windows 10 Enterprise LTSC 2019 / IoT LTSC 2019.

Microsoft’s KB explicitly states the OOB packages address the Reset/Recovery failure and recommends installation for systems that experienced the issue; it also notes that if a device is not impacted or will not use those recovery flows, installing the OOB is optional. (support.microsoft.com)

Delivery and administration notes​

The OOBs appear in Windows Update as optional updates and are also available via the Microsoft Update Catalog for manual deployment and for use in WSUS / management pipelines. Because the packages include an SSU, administrators should be aware of SSU/LCU combined‑package semantics when planning removal or rollback — SSUs are not separately uninstallable once installed. Microsoft documented removal steps using DISM for the LCU component only, but warned that the SSU remains. (support.microsoft.com)

---

The SSD problem: disappearance, RAW partitions, and partial data loss reports​

What community testing and vendors reported​

A separate set of reports, concentrated among enthusiast testers and community threads, described an alarming pattern: certain NVMe/M.2 SSDs — particularly some models using specific Phison controllers and other vendors’ controllers — would stop enumerating during sustained large writes (commonly reported thresholds near ~50 GB of continuous writing or when the drive was heavily used), or would later mount as RAW with inaccessible partitions. In many cases the device reappeared after a reboot; in others, data structures appeared damaged and required imaging or vendor recovery tools. (bleepingcomputer.com)
Multiple independent outlets and testing threads documented affected brands and models in anecdotal reproductions and vendor engagement; however, reproduction was hardware‑dependent and not universal across all drives. Phison (a controller vendor frequently mentioned in repros) and other partners acknowledged investigations. Microsoft confirmed it was investigating storage reports and coordinating with partners. (techradar.com) (bleepingcomputer.com)

Severity and recoverability​

Community evidence suggests two broad outcomes:

• Milder: drive disappears temporarily during heavy writes and returns after reboot; data in flight may be corrupted but the drive is otherwise recoverable.
• Severe: drive remains inaccessible, appears as RAW, or loses partition metadata; recovery may require imaging, vendor tools, firmware reflash, or an RMA — and in some cases full media erase was the only remediation, resulting in permanent data loss.

Because damage seen in many cases is on‑media rather than purely host state, uninstalling the Windows update does not guarantee restoration of corrupted files or metadata. This makes proactive backups the single most important mitigation during an unresolved hardware compatibility incident. (windowscentral.com)

---

Cross‑verification and what we can say for certain​

• Microsoft has publicly documented the Reset/Recovery regression and published OOB fixes (KB5066189, KB5066188, KB5066187). This is confirmed on Microsoft’s support pages. (support.microsoft.com)
• Independent reporting and community telemetry corroborate the regression symptoms and the mapping to the August originating KBs (for example, KB5063875 and KB5063709). (bleepingcomputer.com)
• Reports of SSDs disappearing under heavy writes after the August 12 updates are numerous in community forums and independent tests, and vendors (including Phison) have engaged in investigations; however, a definitive single root cause has not been published by Microsoft or the SSD vendors at the time of reporting. Treat storage failure claims as provisional until vendors publish precise firmware/compatibility findings. (bleepingcomputer.com)

Any statement that implies universal or permanent drive destruction attributable to the update alone is not supported by the currently available evidence; the data shows a pattern of device‑dependent anomalies under specific workloads, not a blanket failure across all SSDs. That nuance is essential for honest technical reporting.

---

Immediate, prioritized guidance for users and administrators​

The risks are real and the mitigations are straightforward. Prioritize continuity and data protection.

• Back up now. Follow the 3‑2‑1 rule: three copies, on two different media, one off‑site. Imaging is recommended for at‑risk drives before any heavy writes or recovery attempts.
• If you already experienced Reset failures, install the OOB for your servicing branch (for example, KB5066189 for affected Windows 11 branches). The OOB supersedes the August LCU and includes SSU components. (support.microsoft.com)
• If you have not installed August updates yet, consider applying the OOB package appropriate for your branch instead of the original August rollup. Microsoft recommends the OOB where the reset regression is a concern.
• Avoid large sequential writes on systems patched with the August 12 packages until vendor guidance or firmware updates are available. This includes large game installs/patches, full‑disk copying, cloning, and mass extraction of archives.
• For fleets: stage OOB deployments in a controlled pilot ring and validate Reset, cloud re‑image, and RemoteWipe operations on representative hardware before broad rollout. Pause any automated reprovisioning that relies on Reset/RemoteWipe until validation completes.

If an SSD disappears mid‑write:

• Stop writing to the drive immediately to avoid further damage.
• Reboot once and check whether the device reappears; if yes, capture vendor SMART and logs.
• If the drive remains inaccessible, image the raw device (dd / vendor imaging tool) if possible and contact the SSD vendor for recovery guidance and RMA; do not reformat if you need to preserve data.

---

Critical analysis: Microsoft’s handling — strengths and weaknesses​

Strengths​

• Rapid acknowledgment and remediation: Microsoft posted a Release Health advisory and shipped OOB packages within days of the first confirmed reports, showing an incident response capability that can operate outside the monthly cadence for high‑impact regressions.
• Use of multiple mitigation channels: Microsoft deployed OOB cumulative updates, leveraged Known Issue Rollback (KIR) for WSUS delivery problems, and coordinated with SSD vendors — a multi‑pronged approach suited to distinct failure modes.

Weaknesses and risks​

• Messaging clarity and UI exposure: the Reset UI and in‑product prompts did not proactively warn users that Reset/Recovery could fail after August updates; the advisory lives on Release Health and KB pages, which many end users do not regularly monitor. That gap risks users discovering the regression mid‑operation.
• Packaging complexity: combined SSU+LCU packages complicate rollbacks and uninstall paths for administrators; SSUs are non‑removable, which reduces options if downstream problems appear.
• Hardware diversity exposure: exhaustive pre‑release testing across the enormous variety of SSD controllers, firmware versions, and host configurations is impractical, but the incident underscores the need for more focused co‑testing between Microsoft and controller vendors to reduce hardware surge risk.

---

Technical hypotheses (what likely happened)​

The definitive root cause has not been publicly released, but available evidence and the symptom patterns point to plausible mechanisms worth noting:

• Servicing/WinRE metadata regression: the recovery regression appears tied to servicing stack/metadata interactions that cause Reset/WinRE flows to abort — a host‑side servicing path error that OOB SSU/LCU packaging addresses. The fact that Microsoft’s OOB bundles an SSU supports this theory. (support.microsoft.com)
• Host/firmware interaction under heavy I/O: the SSD disappearances were consistently reported under sustained, large writes on drives near capacity and in some cases implicated DRAM‑less controllers (Phison and others). Small changes in OS buffering or write sequencing can expose latent firmware bugs or controller corner cases. That pattern is consistent with vendor involvement and the need for firmware fixes or controller microcode updates in some cases. (windowscentral.com)

These hypotheses are consistent with vendor involvement and the two distinct remediation tracks (OOB for recovery, vendor firmware/driver updates for drive stability). Until vendors publish precise firmware revisions or Microsoft shares an engineering post‑mortem, the community should treat root‑cause statements as informed analysis, not conclusive fact.

---

Longer‑term lessons and recommendations​

• Expand automated recovery flow testing: include more diverse storage configurations, high‑stress write patterns, and WinRE permutations in pre‑release suites. Recovery paths must be treated as first‑class QA citizens.
• Strengthen vendor co‑testing: create shared test harnesses with SSD controller vendors to exercise host+firmware interactions under realistic stress workloads during major cumulative cycles.
• Surface critical advisories in‑product: when a known issue undermines a core OS action (Reset, RemoteWipe), raise in‑UI warnings and gating to prevent uninformed users from initiating risky operations.
• Improve update packaging transparency: provide clearer guidance to admins about SSU implications and uninstall limitations when combined packages are delivered. This reduces confusion during emergency remediation. (support.microsoft.com)
• For enterprises: maintain conservative update rings and require image/drive‑level validation in pilot rings, especially where reprovisioning, secure sanitization, or large media operations are business‑critical.

---

What remains uncertain and what to watch for​

• SSD root cause and firmware fixes: vendor advisories, controller microcode updates, or Microsoft engineering notes will be required to conclusively map affected model lists and provide deterministic mitigations for storage anomalies. Until those appear, treat storage reports as investigative and device‑dependent. (bleepingcomputer.com)
• Post‑mortem and transparency: this incident highlights the value of a detailed engineering post‑mortem that explains the chain of events (what in the August rollups caused the regression, why it slipped through QA, and what will change). The community should track Microsoft release health and vendor bulletins for those details.

---

Practical checklist — clear actions to take now​

• For all users:
• Back up critical data immediately; image suspicious SSDs before heavy writes.
• If you experienced Reset failures, install the appropriate OOB (e.g., KB5066189) before attempting Reset again. (support.microsoft.com)
• If you have not applied August updates, consider applying the OOB for your servicing branch instead of the original August rollup.
• For administrators:
• Inventory: enumerate devices that installed August rollups (KB5063875, KB5063709, KB5063878, etc.).
• Stage: apply OOB fixes to pilot rings that represent your hardware mix and validate Reset/RemoteWipe flows.
• Hold: pause automated reprovisioning or large write jobs on recently patched machines until testing clears them.
• Monitor: watch Microsoft Release Health and vendor firmware advisories; deploy firmware fixes only after validating on test hardware.

---

Conclusion​

August’s Patch Tuesday evolution into an incident — a confirmed Reset/Recovery regression fixed by emergency OOB updates and a parallel, still‑investigated set of SSD anomalies under heavy write loads — is a sobering reminder that security rollups and servicing stack changes touch deeply integrated platform subsystems. Microsoft’s rapid issuance of OOB packages (for example KB5066189) was the correct short‑term response for the recovery regression, but the storage reports underscore the limits of pre‑release testing across the wild variety of hardware and firmware combinations in the Windows ecosystem. (support.microsoft.com)
For end users and administrators the immediate priorities remain simple and immutable: back up data, stage updates in representative pilots, apply OOB fixes if you experienced Reset failures, and avoid heavy write workloads on potentially affected drives until vendors and Microsoft publish definitive guidance. The episode should sharpen update strategies and deepen cooperation between OS vendors and hardware partners to prevent similarly painful surprises in future cumulative cycles.

---

Source: SSBCrack Microsoft Issues Emergency Update to Address Critical Windows Reset and SSD Issues - SSBCrack News