Microsoft’s August 12, 2025 cumulative update for Windows 11 24H2, KB5063878 (build 26100.4946), has triggered a narrowly distributed but severe storage regression: during sustained large sequential writes, some NVMe SSDs abruptly vanish from the operating system, with at least one drive rendered permanently unrecoverable in community testing. As Phison—a major SSD controller vendor—publicly acknowledges the reports and begins coordinating with partners, affected users and IT administrators are scrambling to safeguard data and avoid triggering the failure.
The Symptom: Drives That Disappear Mid-Transfer
The first public alarm came from X user Nekorusukii, who reported that while updating Cyberpunk 2077 on a system running the patched Windows 11, the game’s SSD disappeared completely from File Explorer, Device Manager, and Disk Management. A reboot restored visibility, but the drive would vanish again whenever a large file transfer was repeated. That pattern quickly became a reproducible fingerprint.
Multiple independent testers and technology outlets, including Tom’s Hardware, Windows Central, and NotebookCheck, have since confirmed the core symptoms:
- Sustained sequential writes of roughly 50 GB or more—such as installing large games, extracting archives, cloning drives, or copying media libraries—trigger the failure.
- Drives typically above 60% full are disproportionately affected, though this isn’t a hard cutoff.
- The SSD disappears from the OS entirely: not just unmounted, but absent from Device Manager, with vendor SMART tools and controller telemetry becoming unreadable.
- In most cases, a reboot brings the drive back—temporarily. However, a repeat of the heavy write workload usually causes the same disappearance.
- In a small number of reports, drives remain inaccessible even after power cycling. One Western Digital SA510 2TB, part of a 21-drive stress test, reportedly never came back.
The triggers mimic real-world productivity and entertainment tasks: Steam game updates, video exports, large archive extractions, and full-disk cloning. Users on Reddit and X have shared similar stories, including a SanDisk Extreme Pro M.2 NVMe owner whose drive vanished after a 50 GB Honkai: Star Rail update. That user repeatedly encountered the issue until they uninstalled the preview update KB5062660, after which the problem ceased.
Hardware Patterns: Phison Controllers and DRAM-Less Designs in the Crosshairs
Community collations initially pointed a finger at SSDs using certain Phison controller families, especially DRAM-less models that rely on Host Memory Buffer (HMB) for caching. That suspicion aligns with past Windows 11 24H2 incidents where HMB-related changes caused similar symptoms on drives like Western Digital’s SN770 and SN580. However, the current bug is not exclusive to Phison or DRAM-less hardware.
In the 21-drive stress test conducted by Nekorusukii, 12 drives became inaccessible under heavy writes. Those failures spanned multiple controller vendors, though specifics weren’t detailed. The single unrecoverable drive—a WD SA510—uses a different controller lineage, reinforcing that the root cause may be a more subtle interaction between the Windows storage stack, NVMe driver behavior, and individual firmwares.
Attribution remains messy because an SSD is a layered system: NAND, controller firmware, vendor configuration, host platform (chipset/PCIe root complex), and OS timing all intersect. A small change in how Windows allocates HMB buffers or sequences I/O commands can expose a latent firmware race condition. Moreover, different firmware revisions on the same retail model mean that one user’s drive may survive while an identical-looking unit fails.
Phison Acknowledges the Crisis, Microsoft Stays Silent on Storage
Phison’s statement to Tom’s Hardware on August 19 marked the first official vendor acknowledgment:
“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. We understand the disruption this may have caused and promptly engaged industry stakeholders. We are steadfast in our commitment to product integrity and the success of our partners and end users. At this time, the controllers that may have been affected are under review and we are working with partners. We will continue to provide updates and advisories to partners who may have been impacted to provide support and ensure any applicable remediation.”
Notably, Phison’s wording acknowledges “industry-wide effects” and mentions both the August cumulative and the earlier KB5062660 preview, suggesting that the issue may have a longer tail. The company did not provide a root cause or a timeline for firmware fixes, but promised ongoing coordination.
Microsoft, meanwhile, has not listed storage-related known issues for KB5063878. The official KB article initially noted no problems; a later update addressed a separate WSUS/SCCM installation error (0x80240069) using Known Issue Rollback controls. There is no public admission that the update causes SSD failures. This vacuum forces users and administrators to rely on community telemetry and third-party guidance.
What’s Going On Under the Hood? Three Leading Hypotheses
Without vendor forensic logs, the precise causal chain remains unproven. But the symptoms point to a controller-level stall or crash. Community analysis and historical precedent suggest three plausible mechanisms:
- Controller firmware lockup under metadata/caching stress. Extended sequential writes hammer the controller’s metadata path, cache management, and garbage collection routines. If firmware contains an unhandled race condition or resource exhaustion bug, the controller can silently halt—still electrically present on the PCIe bus but unresponsive to host commands.
- Host Memory Buffer (HMB) or NVMe driver timing regression. DRAM-less SSDs borrow system RAM for their mapping tables. If the Windows update altered HMB allocation size, timing, or teardown procedures, it could trigger a firmware crash that leaves the controller unresponsive. The 24H2 feature update already forced fixes for HMB-related disappearances on WD drives, lending weight to this theory.
- Platform/chipset power- or thermal-management edge case. Heavy writes alter controller and chipset power states. A platform-level stall—perhaps involving PCIe link power management—can appear identical to a controller lockup. Disambiguating this requires vendor-specific telemetry that community testers don’t have.
Of these, the HMB and firmware interaction hypotheses are the most consistent with the reported hardware (predominantly DRAM-less and Phison-based drives) and the fact that some users resolved the issue by uninstalling the update. But until SSD vendors release forensic analysis or Microsoft confirms a host-side regression, these remain educated guesses.
Risk Assessment: How Bad Is It?
- Severity per incident: High. When a drive disappears mid-write, files can be truncated or corrupted. In rare cases, the drive may become unrecoverable without professional data recovery. For users without backups, this can be catastrophic.
- Prevalence: Limited but non-negligible. The 21-drive test found 12 failures, but that was a targeted sample heavy on DRAM-less designs. The broader installed base is likely far less affected, as evidenced by the absence of a wider outcry. Still, the cluster is reproducible and concentrated enough to demand immediate caution.
- Permanent hardware loss: Low to moderate in reported cases. Most drives recovered after a reboot. The single reported bricked WD SA510 is alarming but appears to be an outlier so far.
Immediate Actions for Windows 11 Users
- Back up critical data now. The only real defense against update-induced storage corruption is a verified backup on an unaffected medium (external drive, NAS, cloud). Use full-disk imaging if possible.
- Avoid sustained >50 GB writes on systems with KB5063878 installed, especially if your SSD is more than 60% full. Split large transfers into smaller chunks when possible.
- Check your SSD vendor’s utility software for firmware updates. Only apply updates after backing up, and watch for any advisories that specifically mention Windows 11 24H2 regressions.
- If a drive disappears:
- Stop all writes immediately.
- If comfortable with imaging, create a forensic image before attempting any recovery—this preserves data for vendor diagnostics.
- Contact the vendor’s support team and provide SMART logs, Windows Event Log excerpts, and vendor-tool logs.
- For novices: power down, remove the drive if externally accessible, and consult a professional recovery service if the data is critical. - Consider uninstalling the update if you’ve already experienced a disappearance and rollback is operationally acceptable. Because KB5063878 is a combined SSU/LCU, you must use DISM rather than wusa.exe. The command
DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.4946.1.xmay work, but test in your environment and weigh the security trade-off.
Advice for IT Administrators
- Stage deployment in a test ring that includes machines with consumer NVMe SSDs, DRAM-less models, and OEM configurations. Run sustained write tests on non-production data to identify vulnerable combinations before broad rollout.
- Use Microsoft’s Known Issue Rollback (KIR) policies for the separate WSUS delivery error, but do not expect them to address the storage bug unless Microsoft explicitly documents one.
- Ensure vendor firmware repositories are accessible and updated. Coordinate with major SSD suppliers to obtain signed firmware images and testing guidance.
- Update incident response playbooks to include immediate steps for SSD disappearances: stop writes, capture logs, image disks, engage vendor. Consider temporarily blocking the problematic update ring-wide if multiple production systems are affected.
The Long-Term Fix: Firmware + OS Coordination
Historical precedent suggests that remediation will come from both SSD vendors and Microsoft. Phison’s statement indicates that it is working with partners to identify affected controllers and prepare firmware updates. These will likely appear through vendor-branded utilities (Samsung Magician, WD Dashboard, etc.) and must be applied carefully.
If firmware delivery stalls, Microsoft could issue a targeted Known Issue Rollback or registry mitigation that reverses the host-side change that triggers failures. This stopgap would protect users while vendors finalize firmware. However, without an official Microsoft acknowledgment, such a move remains speculative.
For now, the most practical defense is conservative update management, proactive backups, and watching vendor advisories like a hawk.
A Familiar Lesson
This incident echoes earlier Windows storage regressions—from the 24H2 HMB saga to specific SanDisk and WD firmware hiccups. Modern storage reliability hinges on a delicate dance between OS, driver, controller, and NAND. Even a minor host-side tweak can surface a latent firmware bug that went unnoticed for months. For users and IT departments, the takeaway is timeless: updates are essential, but they must be paired with staged rollouts, hardware-aware testing, and immutable backups. Without those, a Patch Tuesday can quickly become a data emergency.
The community’s rapid correlation of the 50 GB write threshold with drive fullness gave vendors actionable telemetry. Now the industry must deliver coordinated fixes. Until then, prudence and preparation remain the only reliable shields.