Windows 11 August 2025 KB5063878 Causes NVMe SSD Disappearances Under Heavy Writes

Microsoft’s August cumulative for Windows 11 (KB5063878, OS Build 26100.4946) has been linked by multiple community tests and specialist outlets to a narrow but severe storage regression in which some NVMe SSDs can suddenly become unresponsive or disappear during sustained, large writes — a failure mode that can leave files truncated, partitions inaccessible, or in a small number of reports, drives unrecoverable.

---

Background​

Microsoft shipped KB5063878 (a combined Servicing Stack Update and Latest Cumulative Update) on August 12, 2025 as the regular Patch Tuesday rollup for Windows 11, version 24H2 (OS Build 26100.4946). Microsoft’s public KB initially noted no known issues with the package, while later release-health updates addressed a separate enterprise install problem (WSUS/SCCM error 0x80240069) using known‑issue rollback controls.
Within days of that rollout, independent hobbyist testers and multiple technology outlets reproduced a consistent failure profile: during sustained sequential writes commonly reported around the ~50 GB mark — and particularly when target SSDs were moderately full (community reports typically cite ~60% fill) — a subset of SSDs would stop responding, vanish from Device Manager / Disk Management and present unreadable controller telemetry to diagnostic tools. Rebooting frequently restored the device temporarily, but the same heavy-transfer workload often reproduced the failure; in a minority of reported cases drives remained inaccessible or suffered apparent data loss. (tomshardware.com, windowscentral.com)
This article synthesizes the community reproductions, vendor responses, Microsoft guidance, and practical mitigation steps for consumers and IT administrators. Key claims and technical numbers below are corroborated with multiple independent sources where possible; any unverifiable or single-source claims are explicitly flagged.

---

What users actually reported​

Core symptoms (consistent, reproducible)​

• During a sustained, large sequential write — for example: installing or updating a large game, extracting a large archive, cloning, or copying tens of gigabytes in one operation — the target SSD can abruptly disappear from File Explorer, Device Manager and Disk Management. Vendor utilities and SMART telemetry may become unreadable.
• The failure typically surfaces after tens of gigabytes of continuous writes; community tests commonly cite a threshold near 50 GB. Many reproductions also report the issue when the drive's used capacity is above roughly 60%. (tomshardware.com, borncity.com)
• In most cases a system reboot restores the drive temporarily. In some reports the drive could not be recovered without vendor intervention or imaging; one community test claimed a Western Digital SA510 2TB device remained unrecoverable. These worst-case reports are serious but remain limited relative to the overall installed base. (tomshardware.com, notebookcheck.net)

Workloads and real-world triggers​

• Typical triggers are realistic consumer and professional tasks: Steam/large-game updates (example: Cyberpunk 2077), downloading or moving entire game libraries, video export jobs, disk-cloning tasks, and extracting very large archives. Community testers and affected users reproduced the failure repeatedly under those heavy sequential write profiles.

---

Which hardware appears to be vulnerable — and why this is complex​

Early community collations and hands-on tests disproportionately implicated drives using certain controller families — notably several Phison controller lineages and a number of DRAM‑less (HMB‑reliant) NVMe designs. That pattern aligns with past incidents where host-side changes to Host Memory Buffer (HMB) allocation or I/O timing exposed firmware corner cases in some controllers. However, the set of reported affected models is inconsistent across testers, firmware revisions, and platform configurations; non‑Phison models also surfaced in isolated reproductions. In short: there is a signal concentrated around particular controller families and DRAM‑less designs, but the phenomenon is not a single‑brand universal failure. (notebookcheck.net, borncity.com)
Why the attribution is messy:

• SSDs are a stacked system: NAND, controller firmware, vendor configuration, host platform (chipset/PCIe root complex), NVMe driver behavior, and OS storage-stack changes can all interact. A small change in host timing or memory allocation can reveal a latent firmware bug that only becomes visible under a specific workload.
• Manufacturer firmware versions vary widely across the same retail model. One drive of a given SKU may be vulnerable while another (different production run or firmware revision) is not. Community model lists are useful investigative leads but not definitive blacklists.

---

Vendor and platform responses so far​

• Phison (a major SSD controller vendor) publicly acknowledged reports and said it was reviewing controllers that may be affected and working with partners to determine remediation steps. That acknowledgement increased credibility for the community reproductions, but Phison's statement did not provide a root‑cause or immediate consumer-facing fix. (tomshardware.com, notebookcheck.net)
• Microsoft’s public KB for KB5063878 initially listed no known issues with the package; Microsoft separately documented and mitigated a WSUS/SCCM delivery error (0x80240069) using a Known Issue Rollback mechanism and updated enterprise guidance. Microsoft has not, at the time of these reports, published a storage‑device Known Issue entry attributing mass SSD failures to the LCU.
• Several enthusiast and specialist outlets (Tom’s Hardware, NotebookCheck, Windows Central, TechRadar and others) aggregated community reproductions and vendor comments while cautioning that a coordinated firmware/OS fix path would be required to fully resolve the interaction. (tomshardware.com, notebookcheck.net, windowscentral.com)

Caveat: vendor statements at this stage are preliminary. Phison’s acknowledgement confirms industry awareness and investigation, but does not confirm whether the root cause is an OS change, controller firmware bug, or a combined interaction that requires fixes from both sides.

---

Technical hypotheses based on community telemetry​

Community technical analysis and the symptom fingerprint point to a few plausible mechanisms — none of them conclusively proven yet, but each consistent with observed behavior:

• Controller lockup under sustained metadata/caching stress: Extended sequential writes exercise controller metadata paths, cache, and internal garbage‑collection routines. If firmware has an unhandled race or a resource exhaustion pathway, the controller can effectively stop responding while remaining electrically present on the PCIe bus, which the host perceives as a vanished drive.
• Host Memory Buffer (HMB) or NVMe driver timing regression: Some DRAM‑less SSDs rely on HMB allocations from the host. If a Windows change alters the timing, size, or lifecycle of HMB buffers, it could expose a firmware assumption and cause a firmware crash or stall under heavy sustained traffic. Prior Windows 11 24H2 interactions documented during the feature rollout produced similar symptoms for DRAM‑less designs, establishing precedent for such interactions.
• Platform/chipset power- or thermal-management edge case: High sustained writes change power states and thermal behavior of the controller and host root complex. A platform-level stall could look identical to a controller lockup at the OS level and would require cross-vendor telemetry to disambiguate. Community reproductions alone cannot fully attribute this possibility.

Practical takeaway: the observable failure mode (sudden disappearance plus unreadable SMART/controller telemetry) is most consistent with a controller-level stall or crash triggered by a specific sustained-write workload — but identifying whether the initiating action is an OS timing change, a firmware bug triggered by new host behavior, or both requires vendor telemetry and coordinated forensic analysis.

---

Verifiable numbers and what they mean​

• Release date / build: KB5063878 published August 12, 2025 (OS Build 26100.4946). This is confirmed by Microsoft’s KB entry.
• Repro trigger reported by multiple independent community tests: sustained sequential writes in the range of ~50 GB or more; drives typically >60% full at time of failure are disproportionately reported. These thresholds come from hands‑on community tests aggregated by specialist outlets and forum investigators. They are reproducible in lab setups but are workload‑specific and not universal for every drive. (tomshardware.com, borncity.com)
• Sample reproduction example: one widely reported thread tested 21 SSDs and found 12 became inaccessible under the test workload; one reported Western Digital SA510 2TB was claimed unrecoverable after the event. Those specific figures are reported by community testers and tech outlets and should be treated as investigative data points rather than a statistically representative sample of all installed SSDs. (tomshardware.com, windowscentral.com)

Flag: community sample sizes and methodology vary; the 21‑drive test provides a concerning signal but is not a comprehensive prevalence study. Treat specific counts from single testers as important indicators that require vendor confirmation.

---

Immediate mitigation steps for consumers (practical, prioritized)​

• Back up critical data now. The single, most important defense against all update-induced storage regressions is a verified, recent backup stored on an unaffected medium (external drive, NAS, or cloud). Imaging tools or full-volume backups are preferable for critical systems.
• Avoid sustained, single-file transfers of very large size (>50 GB) on systems that have recently installed KB5063878 (or KB5062660 if present), especially if the target drive is more than ~60% full. Split large transfers into smaller chunks when possible. Community reports show this is the common reproduction path. (tomshardware.com, easeus.com)
• Check SSD vendor utilities and firmware versions. Where vendor firmware updates are available, apply them only after backing up data. Vendors may publish targeted firmware that fixes controller edge cases; these firmware updates are the most likely long‑term remediation for controller-level faults.
• If an SSD becomes inaccessible mid‑write:
• Stop writing to the drive immediately.
• Create a forensic image (if possible) before attempting destructive recovery; that preserves evidence for vendor diagnostics and maximizes chances of data recovery.
• Contact the SSD vendor’s support and provide SMART logs, Windows Event Log excerpts, and any vendor-tool logs. Vendors may request the image for deeper analysis or RMA.
• For casual users who are not comfortable with imaging: power down, remove the drive if externally accessible, and consult vendor support or a professional data‑recovery service if the data is critical. Reformatting or repeated writes without imaging reduces recovery chances.
• Consider uninstalling the LCU via DISM in environments where the update is demonstrably causing failures and where rollback is operationally acceptable — but note Microsoft’s guidance: because the package is delivered as a combined SSU+LCU, some components cannot be removed with wusa.exe; the supported removal path for the LCU uses DISM /Remove-Package with the package name. Organizations should test rollback steps in a controlled environment, consult vendor guidance, and weigh the security implications of removing a security rollup.

---

Recommendations for IT administrators and managed fleets​

• Immediately stage the August cumulative in a restricted test ring that includes machines representative of the environment’s storage mix (consumer NVMe models, DRAM‑less drives, OEM systems). Execute sustained-write tests (safely, on non‑production data) to identify vulnerable combinations before broad deployment. Community reproductions show the issue can be reliably triggered under certain workloads.
• Use Known Issue Rollback (KIR) and Group Policy controls only as Microsoft directs. Microsoft documented and mitigated a separate WSUS delivery problem for KB5063878 via KIR; follow Microsoft’s release-health guidance for enterprise rollouts. (support.microsoft.com, bleepingcomputer.com)
• Ensure vendor firmware and diagnostics are available in the environment. Coordinate with major SSD suppliers to obtain signed firmware images and testing guidance. If a vendor publishes a targeted firmware update for a controller family, apply it in a staged manner after verification.
• Update incident response playbooks: include immediate-steps for SSD disappearances (stop writes, capture logs, image disks, vendor engagement) and consider temporarily blocking the problematic update ring-wide if multiple production systems are affected.

---

Risk assessment — how severe, and how widespread?​

• Severity per incident: High. When this failure occurs mid‑write it can produce truncated/corrupt files and — in worst cases — inaccessible partitions or drives. Where critical data is on the affected SSD and no recent backup exists, the incident can amount to catastrophic data loss.
• Prevalence overall: Appears limited but non‑negligible. Community tests and aggregated reports show a cluster of reproducible failures across a sampling of drives and platforms, with strong correlation to certain controller families and HMB/DRAM‑less designs. However, Microsoft has not issued a universal storage recall or a KB-known‑issue wording explicitly tying the LCU to mass‑scale SSD failures. Thus, while urgent at the investigative level, the issue currently reads as impactful for a subset of devices rather than a universal failure across all SSDs.
• Likelihood of permanent hardware loss: Low to moderate in reported cases. Most community incidents resolve after reboot or vendor interventions, but a small set of tests reported unrecoverable devices; those reports warrant caution and immediate response from vendors to prevent further instances. (tomshardware.com, notebookcheck.net)

---

How a real remediation path will likely look​

Based on historical precedent and vendor comments, the most likely long-term remediation will combine:

• Firmware updates from SSD vendors (to fix controller-level bugs exposed by new host behavior).
• Possible targeted driver updates or microcode/OS mitigations from Microsoft if host-side timing or allocation changes require compensation.
• Coordinated testing and staged firmware rollouts delivered by SSD vendors through branded utilities to prevent bricking and ensure compatibility. Phison’s public messaging — working with partners to identify affected controllers and prepare firmware updates — reflects this standard coordination model. (notebookcheck.net, tomshardware.com)

If coordination stalls or vendors cannot rapidly deliver firmware, Microsoft could publish a targeted Known Issue Rollback or registry mitigation to revert the host behavior that triggers failures; that would be a conservative, stop-gap approach pending firmware distribution.

---

Clear, practical checklist (for publication and quick reference)​

• Back up critical data now.
• Avoid sustained >50 GB sequential writes on recently patched systems, especially if drives are >60% full.
• Check vendor firmware and update utilities; apply only after backing up.
• If a drive disappears: stop writes, image the disk before recovery attempts, contact vendor support.
• For admins: stage rollout, test heavy-write scenarios on representative hardware, and prepare to block or roll back the update if multiple systems show failures.
• Watch vendor advisories and Microsoft release-health updates for confirmed remediation instructions.

---

Final analysis — strengths, weaknesses, and the broader lesson​

Strengths of the response so far:

• Rapid community reproduction identified a specific workload-triggered failure profile, which gave vendors and Microsoft actionable, testable telemetry early in the incident lifecycle. Multiple independent outlets and hands‑on testers converged on similar trigger thresholds (~50 GB sustained write, drives ~60% full), making the signal actionable for sysadmins and vendors. (tomshardware.com, borncity.com)
• Vendor acknowledgement (Phison) and Microsoft’s enterprise mitigations (KIR for WSUS delivery issue) show the standard industry remediation machinery is engaged: coordinated vendor firmware and platform mitigations are a proven path to resolution in similar past incidents. (notebookcheck.net, bleepingcomputer.com)

Risks and weaknesses:

• Public telemetry is incomplete. Without vendor forensic logs and Microsoft kernel/driver traces, the precise causal chain (host vs. controller vs. combined) remains unproven. Community reproductions are essential but not a substitute for coordinated vendor forensic analysis. Any technical attribution beyond “interaction between host storage stack and some controllers” is currently a hypothesis.
• Sample bias risk: community-tested drives are not a statistically representative sample of the global installed base. While reported failures are serious for affected users, the broader prevalence is uncertain until vendors publish validated lists, telemetry, or wide-scale firmware fixes. Treat community model lists as investigative leads, not definitive recalls.

Broader lesson:
Modern storage reliability depends on finely balanced interactions between OS behavior, NVMe drivers, controller firmware, and NAND management. Even minor host-side changes can expose latent firmware bugs. This incident underlines the necessity of disciplined update practices, representative staging rings for fleets, and robust backup strategies — the last being the fundamental line of defense against update-related data loss.

---

Conclusion​

The August 12, 2025 Windows 11 cumulative (KB5063878) has exposed a narrowly distributed but potentially severe storage regression that can make some NVMe SSDs disappear during sustained, large writes. Multiple independent community tests reproduced a repeatable failure window (commonly near 50 GB writes on drives with ~60%+ usage), and vendor and platform stakeholders are investigating and coordinating responses. Immediate actions are straightforward and urgent: back up data, avoid heavy sequential writes on recently patched systems, follow vendor firmware guidance, and treat any drive disappearance as a potential data-loss event that warrants stopping writes and engaging vendor support.
This remains an active, evolving situation. The practical defensible posture for both consumers and IT administrators is conservative: prioritize backups, stage updates, and apply vendor‑provided firmware only after careful testing. The community’s rapid discovery and cross-checking have produced actionable guidance; sustained remediation will require firmware and possibly OS patches distributed through vendor and Microsoft channels. (tomshardware.com, support.microsoft.com, notebookcheck.net)

---

Source: extremetech.com Windows 11 Update Reportedly Causing SSD Issues During Large File Transfers