Microsoft's August 12, 2025 cumulative update for Windows 11, identified as KB5063878 (OS Build 26100.4946), is at the center of an industry-wide probe after multiple community test benches, independent outlets, and SSD vendors reported that certain solid-state drives can vanish from the operating system during sustained, large write operations. The failure mode has, in a subset of cases, resulted in truncated or corrupted files and, rarely, drives that refuse to re-enumerate without vendor-level intervention.

Within days of the patch's release, a cluster of reproducible community tests and user reports surfaced describing a consistent failure fingerprint: during a continuous, large sequential write—often cited around ~50 GB of sustained data—target SSDs would stop responding, disappear from File Explorer, Device Manager, and Disk Management, and sometimes return unreadable SMART or controller telemetry. While a reboot frequently restored device visibility for many units, data written during the failure window was commonly truncated or corrupted. These observations were aggregated across enthusiast forums, test bench reports, and specialist outlets.

The Bug: Disappearing SSDs Under Heavy Write Loads

The failure signature is striking in its reproducibility. Independent labs and hobbyist test benches converged on a short, repeatable symptom set:

  • A large, sustained sequential write—such as a game installation, archive extraction, disk cloning, or bulk backup—proceeds normally and then stalls or fails after tens of gigabytes are written.
  • The destination SSD becomes unresponsive and disappears from the OS topology, no longer appearing in File Explorer, Disk Management, or Device Manager.
  • SMART attributes and vendor utilities sometimes stop responding or return unreadable values.
  • A reboot often restores the drive’s visibility, but files written during the failure window may be truncated, corrupted, or missing; in a minority of cases, the drive remained inaccessible until vendor intervention, firmware reflashes, or reformatting.

Two practical indicators emerged from multiple reproductions and community collations: sustained writes on the order of ~50 GB in one continuous operation appear to be a common trigger, and drives that are more than 50–60% full were cited more frequently, suggesting that reduced spare area and compressed SLC cache windows increase the likelihood of the fault. These numbers are community-derived heuristics—useful risk indicators but not vendor-certified thresholds—and should be treated as a workload profile rather than a guaranteed trigger.

What the Community Found: Hands-On Reproductions

The incident escalated quickly because a methodical tester in Japan, known as @Necoru_cat on X, published reproducible steps and collated model lists from real-world runs. Out of 21 drives tested on his system, 12 became inaccessible under the heavy-write workload, and a Western Digital Blue SA510 2TB could not be recovered even after a reboot. Other testers, including Japanese outlet NichePCGamer, identified at least eight additional users on X facing similar symptoms. One user with a SanDisk Extreme Pro M.2 NVMe 3D SSD reported that the drive became inaccessible after installing a 50GB update for Honkai: Star Rail, and deleting the KB5062660 preview update resolved the problem.

These hands-on reproductions demonstrated a consistent workload profile leading to device disappearance and, in a minority of cases, unrecoverable drives. The community’s work became central to vendor triage and Microsoft’s outreach.

Microsoft and Phison Respond

Microsoft acknowledged the incoming reports, stating it was “investigating with our partners” and asking affected customers to submit Feedback Hub reports and contact support so the company can collect diagnostics. At the time the update was published, Microsoft’s official KB page listed no known issues, but the company later confirmed awareness of user reports and said its internal testing had not reproduced a clear increase in disk failure telemetry.

Phison, a major NAND controller supplier whose silicon appears in many consumer SSDs, publicly acknowledged it had been made aware of “industry-wide effects” tied to KB5063878 and the related preview package KB5062660. Phison stated it is coordinating with partners to reproduce and triage the issue, but it also publicly disputed a widely circulated internal “leak” that purported to list impacted controllers, taking legal steps against its dissemination. Other SSD vendors and branded makers are assessing telemetry and field reports from their customer bases.

Technical Analysis: Plausible Mechanisms

The observed symptom set points to a host-to-controller interaction that emerges under a narrow sustained-write workload rather than a simple hardware defect. Modern SSD reliability depends on a tightly co-engineered system: the OS storage stack, driver behavior, NVMe command timing, and SSD controller firmware (including SLC caching, DRAM or DRAM-less designs, and garbage collection). Small host-side timing or buffer changes can expose latent firmware edge cases.

DRAM-less SSDs, which rely on Host Memory Buffer (HMB), are particularly sensitive to host memory allocation and timing changes. If a Windows update subtly alters how the host issues write commands, manages buffers, or interacts with HMB, a controller firmware expecting a different timing or buffer pattern might enter an unrecoverable state. The failure mode—disappearing device and unreadable SMART—implies the problem is at or below the controller level, suggesting firmware hang, controller crash, or severe metadata corruption. Definitive root-cause attribution, however, requires vendor telemetry and coordinated forensic analysis of controller logs, power states, NVMe command traces, and memory allocations.

Which Drives Are Affected? The Danger of Unofficial Lists

Early public collations identified a variety of consumer NVMe models across brands and controllers, including drives from Corsair, SanDisk, Kioxia, ADATA, and others. However, these lists varied between test benches and depend on firmware revision, host chipset, BIOS settings, and per-system variables. Critical caveats: the same model may be safe on one firmware and vulnerable on another; host platform variables (chipset, BIOS, NVMe driver, memory configuration, HMB support) influence reproducibility; and community lists are investigative leads—not vendor-validated, exhaustive blacklists. Treat early collations as signals for triage and testing, not indisputable truths.

Real-World Consequences: From Corrupted Files to Unrecoverable Drives

Most reports describe recoverable temporary visibility loss, but the stories that pushed this incident to industry attention were the non-trivial minority: files written during the failure window were truncated or corrupted; some drives returned showing RAW partitions or unreadable controller telemetry; and at least one independent test reported a Western Digital Blue SA510 2TB going unrecoverable in a lab reproduction. While the issue is not universal, the potential for data corruption makes the reports urgent for both consumers and enterprise administrators.

Immediate, Practical Mitigations

Until vendors and Microsoft complete forensic analysis, a conservative, data-protection-first posture is essential:

  • Back up critical data now. Create verified images of any at-risk systems. This is the most reliable protection against corruption.
  • Avoid sustained, large sequential writes on systems that received KB5063878 or KB5062660. That includes large game installs, archive extractions directly to the SSD, cloning operations, and bulk media transfers.
  • Pause update deployment in pilot rings. For enterprise environments using WSUS or SCCM, validate the update in a test ring that includes representative storage hardware and heavy-write workloads before broad rollout.
  • Check for and apply vendor firmware updates for SSDs. SSD makers and controller vendors are the first line of remediation for controller-level edge cases; track official advisories rather than leaked lists.
  • If you suspect a drive has been affected, stop writing to it immediately. Image the drive if possible and contact the SSD vendor for recovery guidance. Avoid low-level operations that could overwrite salvageable metadata.

The Rollback Complication

Because KB5063878 is packaged as a combined Servicing Stack Update (SSU) and Latest Cumulative Update (LCU), standard uninstallation via wusa.exe will not remove the SSU portion. Administrators who need to remove the cumulative component must use DISM Remove-Package with the specific package name for the LCU. This complexity means full rollback is not trivial for most home users and underscores why staging updates and testing representative hardware is essential.

Recovery Options for Affected Systems

If a drive disappears mid-write and later reappears with corrupted files:

  1. Immediately stop intensive I/O to the drive.
  2. Create a sector-level image to preserve evidence for vendor diagnostics or professional recovery.
  3. Use vendor support tools and follow manufacturer guidance on firmware reflashes or safe re-initialization.
  4. If vendor tools cannot detect the drive or telemetry is unreadable, escalate to professional data recovery services—but weigh cost and likelihood of success, as recovery from controller-level failures can be complex and expensive.

Balancing Risk: Security vs. Stability

Delaying a security update is never a decision to take lightly. KB5063878 contains security fixes that address vulnerabilities; withholding updates creates exposure. The practical risk calculus should weigh the severity and exploitability of those fixes against the likelihood that representative storage hardware will encounter the narrow heavy-write workload that triggers the bug. For production fleets, hold the update in a pilot ring, run heavy-write tests, and deploy broadly only after vendors and Microsoft provide validated remediation. For home users, follow vendor advisories, keep backups, and consider postponing non-critical large writes until the situation stabilizes.

Structural Lessons for Storage Reliability

This episode reinforces three enduring truths: storage is a co-engineered stack where an OS change can surface latent firmware defects; representative testing that includes heavy-write workloads is essential for update validation; and verified backups remain the only reliable defense when low-level metadata is at risk.

What to Watch Next

  • August 12, 2025: KB5063878 released for Windows 11 24H2.
  • Mid-August: Community reproductions published; Phison and other vendors acknowledge investigations.
  • Ongoing: Microsoft collects Feedback Hub reports and works with partners; vendors test firmware and host-side interactions. Expect vendor advisories, firmware updates, or a Microsoft servicing-level safeguard in the coming weeks.

Monitor official Microsoft Release Health entries and SSD vendor support pages for validated remediation steps. The incident underscores how quickly a routine monthly update can expose fragile interactions deep in the storage stack—and why caution, backups, and coordinated industry response are the immediate priorities.