Microsoft's latest cumulative update for Windows 11 24H2, KB5063878, has landed with an unexpected payload: a growing number of reports that it triggers NVMe SSDs to drop out of the system during heavy file copies. The bug, which can corrupt data and force hard reboots, has IT administrators hitting pause on their patch schedules and power users scrambling to verify firmware versions.

The Update at a Glance

Released on August 12, 2025, KB5063878 is a security-and-quality rollup that pushes Windows 11 24H2 to OS build 26100.4946. Microsoft bundles a servicing stack update (SSU) with the cumulative update, a combination that makes traditional uninstall paths tricky. According to the official support page, the update package consists of multiple .msu files that must be installed in a specific order using DISM or the Windows Update Standalone Installer. This complexity hints at deep under-the-hood changes—though the KB article itself lists no known issues, leaving community sleuths to fill the vacuum.

The Symptoms: Drives Vanish Under Load

Within days of the release, users on forums and social media began posting about a reproducible failure scenario. The pattern is alarmingly consistent:
- During sustained file transfers—commonly reported at around 50 GB or more—certain NVMe SSDs stop responding entirely.
- The drive disappears from Windows Device Manager, and its SMART data becomes unreadable by any tool.
- A reboot temporarily restores the drive, but the fault recurs under similar write pressure.
- In the worst cases, file system corruption sets in, rendering files unreadable even after the drive reappears.

One user described the experience as “like pulling the plug on a running drive,” with no warning in Event Viewer beyond a cryptic I/O timeout. The predictability makes it a nightmare for anyone moving large datasets, from video editors to database administrators. Not all drives behave identically; some recover after a reboot while others remain inaccessible, and the threshold for “heavy writes” can vary by model.

Which Drives Are Affected?

Community investigators have compiled a list of models that repeatedly show the bug, though no one claims it’s exhaustive. The common thread appears to be controller families—especially Phison-based designs—and DRAM-less architectures that rely on Host Memory Buffer (HMB). Drives named in early reports include:
- Corsair Force MP600 (Phison E16)
- Phison PS5012‑E12 reference boards
- SanDisk Extreme Pro M.2 NVMe (Triton MP28)
- Fikwot FN955 (MAP1602 + WDS X3 9070)
- Kioxia Exceria Plus G4 1 TB (Phison E31T)
- WD Blue SN5000, WD Red SA500 SATA, Corsair MP510, Crucial P3 Plus (some recover after reboot, others don’t)

The variation in behavior—some drives bounce back, others stay dead until a cold power cycle—suggests that the trigger is a firmware-level interaction with the Windows storage stack rather than a simple hardware defect. Notably, not every drive in the above list fails in every system, which is typical of timing- or load-dependent bugs.

The Technical Roots: HMB, Firmware, and the Storage Stack

Why would a cumulative update take down SSDs? Veterans of the 24H2 saga point to a familiar suspect: Host Memory Buffer. Since its launch, Windows 11 24H2 has tinkered with how the operating system allocates a slice of system RAM as cache for DRAM-less NVMe drives. Improper HMB handling can starve the controller or confuse its garbage-collection routines, especially under sustained writes.

The reported symptoms align with a controller crashing during a heavy cache-flush operation. When the drive expects a certain HMB window and the OS changes it on the fly—or fails to acknowledge a completion signal—the NVMe device can enter a fault state that the motherboard’s PCIe root complex sees as a hot-unplug. The unreadable SMART attributes further indicate that the controller has stopped communicating with the NAND, a classic firmware panic.

Phison controllers are overrepresented in the reports, but they’re also the most common NVMe brains on the market. Still, the presence of non-Phison drives like the SanDisk Extreme Pro (Triton MP28) hints that the root cause may be a broader OS-level regression in the NVMe driver or storport subsystem. Some kernel developers suspect a memory leak in the write-cache path that eventually starves the device of buffer credits, but without access to crash dumps, that theory remains unproven.

A Grim History: 24H2’s Storage Stumbles

This isn’t the first time Windows 11 24H2 has clashed with SSDs. In late 2024, a similar HMB-related bug caused BSODs on systems with DRAM-less drives, forcing Microsoft to pull an update and issue an out-of-band fix. Earlier in 2025, a separate issue with Phison E18 controllers caused performance degradation after hot-swaps. The pattern erodes trust: each new cumulative update arrives alongside a collective holding of breath.

The recurrence suggests that Microsoft’s storage stack is increasingly complex, with changes intended to boost performance or security inadvertently triggering dormant firmware bugs. It also underscores the difficulty of testing across the thousands of NVMe models in the wild. Admins are left playing Russian roulette with their production data.

The Official Silence and Its Consequences

As of this writing, Microsoft’s KB5063878 support page shows no acknowledged issues. Major SSD vendors—SanDisk, WD, Kioxia, Corsair, Crucial—had not released a coordinated advisory by the time these reports surfaced. The information vacuum amplifies anxiety: without official guidance, every rebooting drive becomes a potential data-loss event.

The risks are tangible. Unlike a software crash that can be recovered with a clean boot, file system corruption on an NVMe volume can permanently destroy data. Users who rely on the disappearing drive as a system disk may find themselves locked out entirely. In enterprise environments, the bug threatens to corrupt database files or virtual machine images on production servers, especially those running automated backup jobs that saturate the storage bus.

What Should You Do? A Practical Action Plan

Given the absence of an official fix, caution is the watchword. Here’s a tiered approach for consumers and IT pros.

For Individual Users

  1. Pause the update. If you haven’t installed KB5063878 yet, defer it via Windows Update settings until the all-clear sounds. Set a reminder to check back in a week.
  2. Verify firmware. Visit your SSD manufacturer’s website and ensure you’re running the latest firmware. Many vendors quietly release patches that address HMB edge cases—a flash could inoculate your drive.
  3. Stop heavy writes. If you’ve already installed the update and notice glitches, avoid large file copies. If a drive vanishes, shut down the system (don’t just restart) and let it sit for a minute. Then image the drive immediately if it reappears.
  4. Check build version. Go to Settings > System > About or run winver.exe. If you see build 26100.4946, you have the suspect patch.

For IT Administrators

  1. Hold the KB on risky fleets. Use WSUS or SCCM to pause the update for devices with NVMe drives, especially those on the community list. Some admins report that KB5063878 failed to install via SCCM with error 0x80240069—another reason to wait.
  2. Inventory storage hardware. Identify machines with DRAM-less SSDs or Phison controllers. Tools like CrystalDiskInfo can dump controller info remotely.
  3. Stage a pilot. If you must test, set up a sacrificial machine with a known-affected drive and a write-heavy workload (e.g., disk benchmark or a robocopy of large VHD files). Log everything with storport and stornvme ETW traces.
  4. Emergency registry tweak. In extreme cases, you can force the OS to limit HMB allocation by setting HmbAllocationPolicy to 0 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\stornvme\Parameters. This is a performance hit and purely a stopgap until a proper fix arrives. Document the change and revert it once vendors deliver a solution.

Removing the Update

Because the SSU is bundled, the usual wusa /uninstall won’t work. Microsoft advises using DISM with the package name. To find the package, run dism /online /get-packages | findstr KB5063878 and then dism /online /remove-package /packagename:[name]. Note that removing a cumulative update also strips out the month’s security fixes, leaving the system vulnerable until a safe patch is applied—so this is a last resort, not a cure.

What’s Next?

The path forward likely involves a two-pronged fix: a firmware update from SSD vendors and a Windows-side mitigatory patch. Historically, Phison-based drives have required firmware adjustments, while Microsoft may tweak the NVMe driver to handle errant controllers more gracefully. The recent history of 24H2 storage bugs suggests that the ecosystem will adapt—but not before some unlucky users suffer data loss.

For now, the best defense is a good backup. The reports of SSDs vanishing under KB5063878 are a sobering reminder that even routine patches can contain hidden landmines. Until Microsoft and drive makers break their silence, keep your data off the update’s firing line.