Multiple independent reports and reproducible tests have confirmed that the Windows 11 August 2025 cumulative update (KB5063878, OS Build 26100.4946) can cause NVMe SSDs to abruptly disappear during sustained large writes, sometimes resulting in permanent data corruption and inaccessible drives. Both Microsoft and SSD controller maker Phison have now publicly acknowledged the issue and are scrambling to coordinate fixes.

The trouble surfaced just days after Microsoft released the August 12 security rollup. Users on forums and social media began reporting that their SSDs vanished from File Explorer, Device Manager, and Disk Management after large file transfers—such as installing a 50GB-plus game update or extracting a huge archive. Restarting the PC often made the drive reappear, but the bug resurfaced as soon as another heavy write began, and in some cases the drive could not be recovered at all.

Especially alarming were reports of corrupted or truncated files and SSD controllers that went completely non-responsive, requiring vendor-level recovery tools, firmware reflashes, or even a full reformat to become usable again. Japanese tech enthusiast @Necoru_cat replicated the behavior across multiple drives and shared detailed test results, accelerating attention from the storage industry.

What’s Happening: The Symptom Pattern

The failure fingerprint is consistent: a large, continuous write operation—typically exceeding 50 GB—is underway to an SSD that is more than 50–60% full. Midway, the transfer stalls, and the destination drive simply disappears from Windows. The SSD no longer appears in any OS-level tool, and storage utilities like CrystalDiskInfo or vendor dashboards may throw errors or fail to detect the device. A reboot often restores visibility, but files written during the window can be partially written or corrupted. In the worst cases, the drive remains invisible until a power cycle, firmware intervention, or reformatting.

Crucially, the trigger is specific: short, intermittent writes do not cause the failure; only sustained sequential writes of tens of gigabytes seem to provoke it. Testers used workloads such as copying a large game folder, creating and extracting a compressed archive, or cloning a disk partition. The bug does not appear linked to any particular application—it’s the I/O pattern that matters.

Which Drives Are Most at Risk?

The community tests, collated by outlets like Tom’s Hardware and Windows Central, paint a nuanced picture. In @Necoru_cat’s experiment, 12 of 21 SSDs became inaccessible under sustained writes on a system with KB5063878 installed. One drive—a Western Digital SA510 2TB—failed to recover even after a reboot.

The affected models spanned multiple controller families, but drives using Phison controllers were notably overrepresented. That dovetails with Phison’s own public statement, which acknowledged “industry-wide effects” from the KB5063878 and KB5062660 updates and confirmed it was reviewing which of its controllers might be affected.

A common thread emerged around DRAM-less SSDs that rely on the Host Memory Buffer (HMB) feature of NVMe. These drives use a small chunk of system RAM for mapping tables, which makes them sensitive to any OS-level changes in memory allocation or timing. Drives that were more than half full also appeared more vulnerable, likely because reduced spare area and compressed SLC caching change the write stress pattern.

While the bug’s epicentre lies in NVMe SSDs, a few reports mention SATA SSDs and even hard disks—suggesting the root cause is an interaction at the storage stack level, not a single-controller fault.

Technical Root: A Host-Firmware Interaction

Though no definitive root cause has been published, the evidence strongly points to a change in the Windows storage stack—perhaps in the NVMe driver, the I/O scheduler, or HMB management—that exposes latent firmware edge cases. When a large sequential write pushes the controller into sustained garbage collection, tight SLC cache recycling, and high command queue depths, any timing or resource change can trigger an unrecoverable state.

In such a state, the SSD controller stops responding to the host while remaining physically powered. To the OS, the drive has vanished. If internal metadata structures get corrupted, partitions can mount as RAW and data recovery becomes complex. This explains why some drives needed a full reformat and why uninstalling the Windows update does not magically restore corrupted files.

The involvement of HMB-using DRAM-less designs points toward a possible alteration in how Windows allocates or reclaims the host buffer during heavy writes. Even a millisecond-level change in DMA completion timing can cause a controller firmware what amounts to a race condition, leaving it stuck in an error loop.

Official Response: Microsoft and Phison Investigate

Microsoft told multiple outlets that it is “aware of these reports and investigating with our partners.” While the KB5063878 public page initially said “Microsoft is not currently aware of any issues with this update,” the company later issued an out-of-band fix for a separate but serious regression—a broken Reset/Recovery feature—under KB5066189. That OOB update, however, is unrelated to the SSD disappearance bug and does not shield drives from the heavy-write failure.

Phison, whose controllers power many popular consumer NVMe SSDs, issued a statement to Tom’s Hardware: “Phison has recently been made aware of the industry-wide effects of the ‘KB5063878’ and ‘KB5062660’ updates on Windows 11 that potentially impacted several storage devices, including some supported by Phison.” The company added that it is “working with partners” and will provide advisories and remediation as appropriate. This vendor acknowledgment transformed the incident from a gathering of forum anecdotes into a formal industry investigation.

Several SSD brands have since begun posting firmware advisories on their support pages and urging customers to use their dashboard tools to check for updates. However, firmware deployment varies widely; some users may wait weeks for a validated fix depending on their model and region.

Immediate Steps to Protect Your Data

If you have installed the August cumulative update and regularly perform large file transfers, backing up critical data is your single most effective defense. Follow the 3-2-1 rule: three copies, two different media types, one offsite (or cloud). Do this before staging any large writes.

Specifically:

  • Avoid sustained writes larger than about 50 GB on any NVMe SSD until you have installed a vendor-recommended firmware update.
  • If you haven’t yet installed KB5063878, consider pausing the update, especially on systems used for content creation, software development, or disk imaging.
  • Open your SSD vendor’s management software (Samsung Magician, Crucial Storage Executive, WD Dashboard, etc.) and check for firmware advisories. Apply updates only after you have a verified backup.
  • If a drive disappears during a write, power down the system (if safe) and avoid repeated writes that could deepen metadata damage. Capture any available logs via Event Viewer or SMART tools, and contact the drive manufacturer for recovery guidance.

For those already affected, uninstalling KB5063878 (go to Settings > Windows Update > Update history > Uninstall updates) may stop the problem from recurring, but it will not repair already corrupted files or restore a bricked drive. In severe cases, professional data recovery or an RMA may be the only option.

Enterprise IT: Containment and Preparedness

For IT administrators, this episode underscores why cumulative updates must be staged and validated against real-world workloads before broad deployment.

Immediate actions:

  • Inventory all Windows 11 24H2 endpoints that have received KB5063878, focusing on machines with NVMe storage used for heavy I/O (e.g., video editing workstations, build servers, virtual desktop hosts).
  • Use WSUS, Microsoft Intune, or your RMM platform to delay the August rollup on unprotected hardware until your SSD vendor publishes a validated firmware update.
  • Communicate with employees: instruct them to avoid large file copies and to back up critical work data to an alternative storage medium or cloud service.
  • Monitor Microsoft’s Release Health Dashboard and your SSD vendors’ support channels. Note that the OOB recovery fix (KB5066189) is important but does not resolve the SSD disappearance issue.
  • If a drive fails, capture forensic data (system logs, SMART dumps) before attempting any repair, and engage both the SSD vendor and Microsoft Support for analysis.

Outlook and Lessons

The speed with which Microsoft and Phison moved from initial reports to public acknowledgment is encouraging, but the incident exposes gaps in pre-release validation. Modern SSDs—especially DRAMless, HMB-reliant models—are deeply co-engineered with the OS. A seemingly minor change in memory buffer handling or I/O scheduling can cascade into a controller crash. Rigorous stress testing that includes sustained sequential writes, full-drive scenarios, and a representative mix of controller architectures should be a mandatory part of each cumulative update’s flight cycle.

For now, the practical advice remains conservative: back up your data, pause heavy I/O on patched machines, and run only vendor-approved firmware. Once validated firmware and any required Windows-side mitigations arrive, they will be distributed through normal update channels. Stay tuned to official support pages and reputable tech outlets for the latest developments.

The most critical takeaway for every Windows user is that no software patch—security or otherwise—should be trusted to play nicely with your storage until you have a current, tested backup. Hardware failures triggered by software updates are rare but devastating; the KB5063878 saga is a stark reminder that proactive data hygiene is the ultimate safety net.