Microsoft’s latest cumulative update for Windows 11 24H2, released on August 12, 2025, is causing certain NVMe SSDs — particularly those with Phison controllers — to vanish from the system during heavy write operations, often leading to file corruption. The patch, designated KB5063878 and bringing the OS build to 26100.4946, has prompted widespread warnings from testers and community researchers who have reproduced the failure under controlled conditions. Users performing large sustained writes exceeding 50 GB, or pushing controller utilization above 60%, may find their drives completely disappearing from File Explorer, Disk Management, and Device Manager. While a reboot often restores visibility, repeating the workload reliably triggers the same failure — and in many cases, the underlying data structures become damaged.

The problem has not been acknowledged as a known issue in Microsoft’s official documentation for the update, but independent technical analyses point to a likely regression in how Windows handles the Host Memory Buffer (HMB) for DRAM-less SSDs. This class of drive, which lacks onboard DRAM and instead borrows system memory for caching, appears especially susceptible. Phison-based models — widely deployed in consumer NVMe drives — account for the majority of reports. A smaller number of hard disk drives have also exhibited similar symptoms, suggesting the flaw may extend beyond HMB-specific logic into the storage driver stack itself.

What users are experiencing

Reports compiled from community forums, social media, and reviewer test benches detail a consistent pattern. During or immediately after a large sustained file write — test cases commonly transfer 50–100 GB of data — the target drive completely disappears from Windows. SMART attributes become temporarily unreadable, the drive no longer appears in device enumeration, and any ongoing operations grind to a halt. After a reboot, the drive returns, but partitions may present errors or be entirely inaccessible. More alarming, repeated exposure to the trigger workload is known to corrupt files and damage partition tables, turning what initially looks like a transient glitch into permanent data loss.

“I was extracting a 80 GB archive directly to my game SSD when the progress bar just froze,” one forum user reported. “Then the drive was gone — not in This PC, not in Disk Management. After restarting, Windows said the drive needed to be formatted.”

Affected configurations share several risk factors:
- Drives that are moderately to heavily filled, with test beds often using volumes at around 60% capacity.
- SSDs based on DRAM-less designs, where the controller relies more heavily on the system’s memory caching.
- Firmware versions that have not been recently updated by the vendor.
- Workloads consisting of large sequential writes: game installs, archive extraction, local backups, video editing scratch disk usage.

The technical roots: HMB and driver regressions

To understand why certain drives are disproportionately impacted, it helps to look at the Host Memory Buffer feature of the NVMe specification. DRAM-less SSDs omit a dedicated DRAM chip to lower cost, and instead allocate a portion of the host computer’s system memory to serve as a cache for the flash translation layer (FTL) mapping tables. The OS manages this allocation through the NVMe driver, granting and revoking memory regions as needed. When the system is under sustained write stress, the controller must constantly update its mapping structures, and the interplay between the host’s memory management and the drive’s firmware becomes intense.

In the case of KB5063878, testers and analysts suspect that a change in the OS’s HMB allocation logic — possibly within the storport or stornvme driver — is leaking memory mappings or delivering corrupted buffer addresses when the controller is hammered. This can push the drive into an unrecoverable state: the controller stops responding to NVMe commands, and Windows enumerates the device as offline. Because SMART data is also inaccessible during this state, the drive appears completely dead until power-cycled.

Phison controllers are not inherently defective. They happen to be widely used in the consumer market, especially in budget-oriented DRAM-less SSDs. Consequently, they occupy a larger slice of the risk surface for this specific regression. A few users with DRAM-equipped SSDs and even some HDDs have reported similar symptoms, though at higher load thresholds. That broader footprint hints that the bug may reside not solely in HMB code but also in the lower-level storage I/O path — possibly the storport miniport layer — that processes write requests under extreme conditions.

The strength of the evidence

What makes these reports more than anecdotal noise is the reproducibility. Independent testers have published step-by-step reproductions: create a large file set, fill the target drive to roughly 60%, and then perform a sustained write to it. Within minutes, the drive disappears. Reboot, repeat, and the failure occurs again — often with the added sting of partition corruption if the write was mid-flight during the first disappearance. Several respected technology outlets have also verified the behavior in their labs, adding weight to the claim.

Vendor responses are trickling in. Some SSD controller makers have privately acknowledged investigations into potential interactions between recent Windows updates and their firmware, and a few have already released updated firmware that they claim mitigates the problem. However, Microsoft’s official update history page for KB5063878 did not initially list any known issue matching these symptoms — a common scenario early in a patch cycle before telemetry and engineering backlogs catch up.

There are limitations to the current dataset. The issue is not universal; many users running identical patched systems have not encountered the bug, likely because their workloads never reach the critical write intensity or their drive firmware is already patched. The reports are also heavily skewed toward a single thorough tester whose methodology may influence how the problem is characterized. Nonetheless, the potential for unrecoverable data corruption makes even a low-probability risk unacceptable for anyone who lacks current backups.

Immediate steps to protect your data

If you rely on a single NVMe drive for your operating system and files, treat this update as a credible threat until you have verified that your specific hardware is safe. Here is what every Windows 11 24H2 user should do right now:

  1. Back up critical data. Copy essential documents, photos, and project files to an external drive, network location, or cloud service. Assume that any data residing solely on a potentially affected SSD could be lost without warning during a large file transfer.
  2. Delay or pause Windows Update. If you have not yet installed KB5063878 and you perform heavy writes — or if your machine uses a DRAM-less Phison NVMe drive — pause updates for at least a week. Open Settings → Windows Update → Pause updates. Enterprises should use Windows Update for Business or WSUS to hold the patch and apply a safeguard hold for systems with vulnerable SSD models.
  3. Update SSD firmware immediately. Visit your drive manufacturer’s support page and download the latest firmware updater. Many vendors have already published patches in response to this regression. Follow the vendor’s instructions carefully and back up your data before flashing.
  4. Avoid large sustained writes. Defer game installs, large archive extractions, video rendering, or local backups that directly target the SSD until you are confident your firmware and OS combination is safe.
  5. If you’ve already experienced a drive failure: Stop all writes to the drive at once. Do not run chkdsk or third-party repair utilities that write to the disk, as this can overwrite damaged data structures. If the data is irreplaceable, use a read-only imaging tool such as ddrescue to capture a forensic image, then contact a professional data recovery service. For less critical data, you may attempt to uninstall KB5063878 via DISM or roll back using System Restore, but note that this will not repair already-corrupted files.

A community workaround involving a registry change to limit HMB allocation size has been floated, but it should be treated as a last resort. Adjusting HMB behavior can degrade performance and cause unintended system instability. The only reliable fixes remain a vendor firmware update or an official Microsoft patch.

What vendors and Microsoft should do next

The storage ecosystem faces a delicate race. Controller vendors and SSD manufacturers need to release firmware that works around whatever kernel path the August update has destabilized. Ideally, they should coordinate with Microsoft to deploy the firmware through Windows Update as a driver update, ensuring that users are protected without manual intervention.

Microsoft, for its part, should immediately publish a known-issue notice on the KB article and implement a safeguard hold that prevents the update from being offered to systems with affected hardware IDs. That is the standard practice for update-related hardware incompatibilities, and its absence here leaves everyday users exposed. The company must also accelerate its investigation, identify the offending code change, and release a follow-up fix — either as an out-of-band update or in the next Patch Tuesday cycle — that restores stable HMB behavior and corrects the storage path regression.

Historical echoes: a recurring pattern

This is not the first time that a Windows update has clashed with SSD firmware over HMB allocation. In 2023, several Western Digital and SanDisk NVMe SSDs suffered widespread crashes and Blue Screens of Death after a Windows 11 update introduced a change in how the OS allocated buffer memory. That incident was resolved only after months of collaborative debugging between Microsoft and the drive vendor, culminating in updated firmware and a revised driver. The current situation follows an eerily similar script: a silent change in the update, a wave of user reports, and an initial reluctance to formally acknowledge the problem.

The recurrence highlights the fragile dependency modern SSDs have on host OS behavior. DRAM-less drives, in particular, are sensitive to even small tweaks in memory allocation patterns. As Microsoft continues to evolve the Windows storage stack — introducing new features like DirectStorage optimizations and refined NVMe handling — the risk of such regressions grows. Testing coverage must therefore extend beyond internal Microsoft labs to early engagement with major controller vendors and a broader fleet of hardware before cumulative updates reach the general public.

Who should be most concerned

  • Power users and enthusiasts who frequently install large games, manipulate huge media files, or run local backup scripts that hammer a single SSD.
  • Creative professionals using NVMe drives as scratch disks for video editing, 3D rendering, or high-resolution photo manipulation.
  • IT administrators managing fleets with a mix of consumer-grade SSDs, particularly those from smaller system builders who may not push firmware updates aggressively.
  • Anyone storing irreplaceable data on a single internal drive without a recent, verified backup.

Casual home users with intermittent, light write patterns are less likely to ever trigger the edge case, but they should not ignore the advice to back up and check for firmware updates. The nature of the bug means that it can strike without warning during an unusually large download or system upgrade.

Forward outlook

The industry will almost certainly produce a combination of fixes in the coming weeks. Firmware updates from Phison and other affected controller manufacturers will arrive first, addressing the drive-side behavior that crashes under the updated OS path. Microsoft will likely follow with either a Windows update that rolls back the HMB regression or a formal safeguard that blocks the patch on known-vulnerable configurations. For enterprise customers, deployment rings and compatibility holds should be in place already to prevent wide exposure.

Until then, caution is the only sensible policy. The promise of faster, cheaper storage has come with an underside: an intricate dance between OS and firmware that can falter in unexpected ways. Backups, firmware hygiene, and a measured approach to updates remain the three-legged stool that keeps data safe in an era where a routine Patch Tuesday release can instantly turn an SSD into a brick. If your livelihood or memories reside on an NVMe drive, spend the fifteen minutes required to run a backup and check your firmware version. That small investment could save you from an otherwise irreversible loss.