The August 12 cumulative update for Windows 11 24H2 (KB5063878, OS Build 26100.4946) is causing a disturbing number of SSDs to suddenly disappear from systems during sustained large file writes. Independent testers, hardware labs, and community reports have confirmed the problem, with some drives becoming permanently inaccessible. Microsoft and storage controller maker Phison have acknowledged the issue and launched investigations, while users scramble for mitigations.

The Update That Broke Storage

Shipped as a combined servicing-stack and cumulative update, KB5063878 landed on Windows 11 24H2 machines with the usual roster of security and quality fixes. Within days, however, enthusiasts and testers noticed a grim pattern: during heavy sequential writes—game installs, large file copies, backup imaging—target NVMe SSDs would simply drop off the system. The drives vanished from File Explorer, Disk Management, and Device Manager, often leaving behind corrupted or truncated files.

The trigger appears remarkably reproducible. Multiple sources converged on a heuristic: a continuous write of roughly 50 GB or more on a drive that is already about 60% full. While these numbers are empirical and not absolute thresholds, they have held consistent across independent labs and user reports. A reboot often restores the drive, but the same heavy workload triggers the failure again, and in a minority of cases, the drive never comes back without vendor-level intervention.

Reproducing the Problem: A Stress Test Gone Wrong

Japanese researcher Nekorusukii (@Necoru_cat) first sounded the alarm when updating Cyberpunk 2077. His SSD disappeared mid-write, and subsequent testing revealed a broader flaw. In a controlled experiment, he tested 21 drives by copying a large game library folder and then extracting a compressed archive. A staggering 12 of the 21 drives became inaccessible. One Western Digital SA510 2 TB could not be recovered even after a reboot.

His findings, corroborated by Japanese outlet NichePCGamer and multiple Western tech sites, showed that the issue spans multiple controller families and brands. Another user reported that their SanDisk Extreme Pro M.2 NVMe 3D SSD vanished after installing a 50 GB Honkai: Star Rail update; the problem repeated until they uninstalled the KB5062660 preview update (a related patch). Tom’s Hardware, BleepingComputer, and Windows Central all independently reproduced the symptom profile, confirming it is not a fluke.

The Hardware Fingerprint: Does It Need Phison? Not Exclusively

Early online chatter pointed a finger at Phison controllers, especially DRAM-less models that rely on Host Memory Buffer (HMB). Phison issued a statement: “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 is investigating and will provide firmware updates and advisories to partners.

However, the testing reveals that drives with other controllers also fall victim. The Tom’s Hardware test matrix included failures across brands and controller types, and at least one drive with a non-Phison controller became permanently bricked. This suggests the root cause lies in a host-side change—perhaps in the storage stack’s buffer management or queue timing—that exposes latent firmware bugs in multiple SSD lines. Community-compiled model lists are evolving but remain provisional; Phison has even taken legal steps over a falsified internal document circulating on social media, underscoring the risk of unverified leaks.

Plausible Root Cause: Host-Side Changes Exposing Firmware Bugs

Modern NVMe SSDs are tightly coupled with the operating system. They use DMA, SLC caching, garbage collection, and often HMB for mapping tables in DRAM-less designs. A regression in the Windows storage driver—perhaps affecting how memory buffers are allocated or flushed—could throw a controller into an unexpected state during sustained, heavy writes. When a controller hangs or resets, it can stop responding to host commands, making the drive disappear. Unreadable SMART telemetry supports this theory: the controller is so wedged it cannot report its status.

This incident mirrors past storage bugs where a seemingly minor kernel patch exposed firmware race conditions. The community’s working hypothesis is that KB5063878 altered timing or buffer handling enough to trip controllers that were otherwise stable under lighter loads. Microsoft has not released a root-cause analysis, but the company’s request for diagnostic dumps from affected users suggests it is exploring this exact scenario.

Who Is at Risk? And How Bad Can It Get?

The failure is not universal; most everyday users will never see it. Risky configurations include:
- Windows 11 24H2 with KB5063878 or KB5062660 installed.
- NVMe SSDs with certain controller families (Phison dominates early lists, but others are affected).
- Drives subjected to sustained sequential writes exceeding roughly 50 GB.
- Drives with relatively high fill levels (community reports around 60% or higher).

Damage varies. Most commonly, files written during the failure window are truncated or corrupted. A reboot usually brings the drive back, but the repeated failure can corrupt file systems over time. In the worst cases—like the Western Digital SA510—the drive becomes unrecoverable, requiring vendor firmware reflash or RMA. For anyone without rigorous backups, the result is permanent data loss.

Mitigation: What You Can Do Right Now

For consumers:
1. Back up immediately. Follow the 3-2-1 rule (three copies, two media types, one offsite). Backups are your only salvation if the drive’s metadata gets fried.
2. Avoid large continuous writes. Split transfers into sub-50 GB chunks where practical. If you must install a 100 GB game, do it in smaller batches or temporarily move the library to a drive that doesn’t exhibit the bug.
3. Check your update status. Open Windows Update history and look for KB5063878 or KB5062660. Microsoft’s support page lists the build number.
4. Roll back if necessary. Because the package includes a servicing-stack update, you cannot uninstall it via the standard wusa.exe method. Use DISM Remove-Package with the package name to remove only the cumulative update portion. Ensure backups are intact before doing this.
5. Gather diagnostics. If you hit the bug, collect Event Viewer logs, Reliability Monitor data, and any SMART outputs. File a report via the Feedback Hub or contact Microsoft Support for Business—the company has asked affected users for exactly this data.

For IT administrators:
- Stage the update. Halt broad deployment of KB5063878. Use pilot rings to test on representative hardware, especially any machines with consumer-grade NVMe drives.
- Inventory storage controllers. Identify systems with Phison-based or DRAM-less SSDs and prioritize them for testing.
- Block large write jobs on pilot systems. Avoid deployment imaging, large media copies, or mass data migrations when testing the update.
- Collect telemetry. If a drive vanishes in your environment, open a case with the drive vendor and Microsoft, and share forensic dumps to accelerate root-cause analysis.

Recovery Steps for a Vanished Drive

If an SSD disappears mid-write, follow these steps to preserve forensic value and maximize recovery chances:

  1. Stop all heavy writes immediately. Avoid multiple reboot attempts; each cycle may degrade the controller state further.
  2. Check BIOS/UEFI. If the drive is still detected there but not in Windows, use the drive vendor’s diagnostic tool to query the device and collect logs. Do not reformat.
  3. Perform a cold power-cycle. Many controllers recover after a full shutdown, power cable removal, 30-second wait, and restart. Check BIOS detection before booting the OS.
  4. If the drive remains dead and data is critical, contact professional recovery. Repeated DIY attempts can worsen the situation.
  5. Preserve evidence. Note the exact Windows update history, time of failure, and any vendor diagnostic outputs. Open a support case with Microsoft and the SSD vendor, providing all the data they request.

Systemic Lessons and the Way Forward

The KB5063878 incident reinforces three enduring truths about modern storage:
- Storage is co-engineered. OS driver, NVMe protocol, controller firmware, and UEFI all interact; a tiny host-side change can surface deep firmware flaws.
- Test rings must include heavy I/O workloads. Update validation often focuses on light desktop tasks. Realistic scenarios—game installs, large backups, clone operations—catch rare but severe regressions.
- Backups trump everything. When low-level storage metadata is threatened, a comprehensive backup strategy is the only reliable safety net.

What to Watch Next

  • Microsoft’s release-health dashboard. The KB5063878 page currently lists no known issues, but that will likely change as the investigation matures.
  • Phison’s firmware advisories. The company has promised partner bulletins; a firmware fix is the probable remediation path if controller logic is at fault.
  • Independent validation. Labs at Tom’s Hardware, BleepingComputer, and others will be the first to test any fixes. Wait for their verified results before trusting that the coast is clear.
  • Official affected-model lists. Avoid relying on community-sourced spreadsheets. Only vendor or Microsoft advisories should be used to make wholesale hardware decisions.

Bottom Line

The evidence is more than anecdotal—repeated reproductions, vendor acknowledgments, and lab studies make KB5063878 a real and actionable risk. Back up your data now. Avoid heavy writes on patched systems until fixes appear. IT managers should throttle deployment, inventory at-risk drives, and prepare for firmware updates. Microsoft and Phison are engaged, but until validated mitigations ship, conservative storage hygiene remains the smartest defense.