A wave of reports across enthusiast forums and hardware labs confirms that the Windows 11 August 2025 cumulative update, KB5063878, is causing certain NVMe SSDs to vanish during prolonged write operations. The trigger? Sustained sequential file transfers that push past the 50 GB mark, exposing latent firmware bugs in a range of DRAM-less and DRAM-equipped drives. Users describe drives simply disappearing from File Explorer, Device Manager, and Disk Management mid-copy. In worst-case scenarios, the drive stays gone even after a reboot—taking its data with it.

How It Started

The issue first surfaced when an X user, @Necoru_cat, tried updating Cyberpunk 2077 on a Windows 11 24H2 system running OS Build 26100.4946 (KB5063878). Halfway through the large download, the target NVMe SSD blinked out of existence. Restarting brought it back, but the problem repeated consistently with any heavy write activity. The user’s methodical testing—copying Steam libraries, extracting archives, and writing large compressed files—produced a reproducible pattern. Tech outlets including Tom’s Hardware, NotebookCheck, and Guru3D amplified the findings, and community testers worldwide began logging similar failures.

What Happens When an SSD Disappears

The typical symptom is dramatic. During a sustained sequential write, the drive becomes unresponsive and disappears from every OS interface. SMART telemetry may become unreadable, and any in-progress writes are lost. A reboot often restores visibility, but files written during the failure window frequently come out corrupted. In rare but alarming cases—such as one Western Digital SA510 2 TB tested in the original investigation—the drive could not be recovered at all, even after power cycling. The community’s shared evidence points to a threshold: writes exceeding roughly 50 GB on a drive that’s already more than 60% full. Not every drive hits that line neatly; some fail earlier, others later, and many not at all.

The Technical Underpinnings: HMB and Sustained Writes

To understand why a Windows update would cause SSDs to vanish, you have to look at Host Memory Buffer (HMB). HMB is an NVMe feature that lets DRAM-less SSDs borrow a small slice of system RAM for mapping tables and metadata—a trick that keeps them competitive on performance. When Microsoft tweaks how Windows allocates or reclaims that buffer, it can nudge a controller’s firmware into a code path it was never thoroughly tested against. Add sustained writes, and the drive’s internal garbage collection, queue management, and thermal throttling all pile on top of the HMB traffic. A controller hang or metadata corruption becomes far more likely.

Heavy sequential writes are especially cruel. They stress the drive in ways that everyday desktop use doesn’t. Long, uninterrupted streams fill internal caches, force the flash translation layer to scramble, and run DMA engines flat out. The result is a perfect storm for exposing race conditions and edge-case bugs that have lurked silently inside the firmware for years.

Which Drives Are Reported Affected?

Community collations are broad but uneven. The most frequently named controllers are from Phison’s PS5012-E12, E21T, and E31T families, which power popular models like the Corsair Force MP600, some Kioxia Exceria Plus G4 variants, and the Crucial P3 Plus. Western Digital and SanDisk models—WD Black SN770, WD Blue SN580, WD Blue SN5000, and SanDisk Extreme—also appear repeatedly, echoing earlier HMB-related incidents with 24H2. However, test benches varied: a drive that fails on one motherboard/CPU combo might sail through on another. PCIe lane negotiation, BIOS settings, and memory timings all muddy the waters.

Crucially, the original investigation’s list of 21 drives included models with non-Phison controllers as well, and 12 of them became inaccessible under the same write load. Only the Western Digital SA510 suffered apparently permanent corruption. That suggests the underlying bug isn’t confined to a single controller family; it’s a broader compatibility problem that manifests differently on each firmware/hardware stack.

Vendor and Microsoft Responses

Microsoft’s KB5063878 page initially reported no known issues. As user complaints mounted, the company acknowledged separate deployment headaches—a 0x80240069 error hitting WSUS and SCCM installations—but avoided directly linking the SSD disappearances to the update. Instead, the typical OS-vendor playbook kicked in: upgrade-health blocks prevented 24H2 from being offered to systems running known-vulnerable firmware, giving SSD makers time to patch.

Western Digital acted first. The company rolled out targeted firmware updates for the SN770, SN580, SN5000, and SanDisk Extreme, adjusting HMB handling specifically for Windows 11 24H2. Phison released a statement confirming it was “working with partners” and reviewing potentially affected controllers. Intel and other vendors stayed quieter, leaving community testers to fill the gaps.

Across the board, the official advice crystallized: back up your data, check your SSD’s firmware version with the vendor tool, and apply any available patch before trusting the drive with heavy writes.

Testing and Reproductions

The original X investigation wasn’t a one-off. Tom’s Hardware, NotebookCheck, and Guru3D all performed independent reproductions. Testers used large game installs, synthetic sequential-write benchmarks, and real-world archival tasks. The common thread was a sustained write stream exceeding ~50 GB on a drive with moderate-to-high occupancy. A few testers also noted that resetting the system’s power completely (full shutdown, not just restart) sometimes recovered a hidden drive, suggesting that certain failure states lock the controller in a low-level hang that only a cold boot can clear.

What the tests could not fully resolve is the exact boundary between a mere disappearance and permanent data loss. In most documented cases, a reboot brought the SSD back, albeit with a corrupted file system if writes were in flight. True hardware bricking—irreversible controller-flash corruption—appears rare. For the average user, the operational impact is the same: inaccessible files drive unreadable partitions, and a very real risk to data integrity.

Practical Guidance for Users

If you’re running Windows 11 24H2 with KB5063878 (OS Build 26100.4946), take these steps now:

  • Back up immediately. Use an external drive or cloud sync before doing anything else. A large write during the backup could itself trigger a failure, so proceed carefully and verify the backup’s integrity.
  • Identify your SSD model and firmware. Check Device Manager or run the vendor’s dashboard tool (WD Dashboard, SanDisk Dashboard, Crucial Storage Executive, Samsung Magician, etc.). Compare your firmware revision against the vendor’s latest release notes.
  • Apply any available firmware update that mentions Windows 11 24H2 compatibility. Western Digital’s patches, for example, are specifically designed to resolve HMB-related crashes and disappearances. Do this only after a verified backup.
  • If no firmware fix exists, consider limiting or disabling HMB allocation as a temporary workaround. Advanced users have reported success modifying the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorPort\HmbAllocationPolicy. Values of 0 (disabled) or 1 (limited) can prevent the crash, but they will degrade performance. Export the key before making changes, and understand that this is a last-resort mitigation.
  • During any large file transfer, monitor Event Viewer for NVMe I/O timeout errors or storahci/stornvme warnings. If a drive vanishes mid-transfer, halt all disk activity, note the timestamp and symptoms, and perform a graceful shutdown (not restart). Avoid repeatedly power-cycling a drive that stays invisible—further writes can worsen corruption.

Remember: firmware updates and registry edits carry their own risks. Always back up first.

Broader Implications for IT Teams

For enterprise administrators, this incident is a textbook example of why phased rollouts matter. Use WSUS or SCCM to stage KB5063878 to a pilot group of test machines with representative hardware before broad deployment. Monitor vendor Security Advisories and Microsoft’s release-health dashboard for known-issue additions. If your organization relies on high-throughput storage—video editing, database replication, log ingestion—the interaction between OS-level storage changes and diverse SSD firmware is a risk you cannot ignore.

The same lesson applies to enthusiasts and system builders: a Windows cumulative update is never “just a security patch.” Storage stack changes, even those buried in the release notes, can act as Trojan horses that turn a stable machine into a data-loss machine. A verified backup remains the single strongest defense.

Conclusion

KB5063878 does not “brick” SSDs in the sense of physically destroying them. But by altering HMB allocation and other low-level behaviors, it reliably exposes firmware weaknesses that make NVMe drives disappear, corrupt data, and in rare cases render partitions permanently unreadable. The scope is broader than any single controller family, and the community’s rapid detection—paired with vendor firmware updates and Microsoft’s rollout protections—has prevented what could have been a mass disaster.

If you’re affected, the path forward is clear: back up, update firmware, and avoid heavy writes until you’re certain your drive is stable. If your vendor hasn’t yet released a fix, the temporary HMB registry workaround offers a pragmatic, if imperfect, safety net. This episode underscores an uncomfortable truth about the modern PC ecosystem: when the host changes its assumptions, it’s up to the SSD firmware to keep up—and when it can’t, your files pay the price.