Microsoft’s August 2025 cumulative update for Windows 11 24H2, KB5063878 (build 26100.4946), is triggering a disturbing storage regression that causes SSDs to vanish from the operating system under heavy write loads. Community testers have reproduced the issue across multiple drive models, with one drive becoming permanently unrecoverable in at least one documented case. The problem has prompted SSD controller designer Phison to publicly acknowledge an investigation, though Microsoft has yet to issue an official root-cause analysis.

Within days of the update’s release on August 12, enthusiasts and specialist outlets began reporting an identical failure fingerprint. When a target drive is subjected to sustained sequential writes—typically tens of gigabytes—the drive can stop responding, disappear from File Explorer, Device Manager, and Disk Management, and return unreadable SMART or controller telemetry. Some drives recover after a reboot; others do not, leaving data written during the event corrupted or lost.

The symptom profile: 50 GB and beyond

The trigger is remarkably consistent. Multiple independent reproductions confirm that large, sustained sequential writes are the necessary condition. Community test logs point to a threshold around 50 GB of continuous data transfer, with an elevated risk when the drive is more than 60% full. Operations that routinely generate such workloads—game installations, archive extractions, disk cloning, or bulk media copies—have become minefields on affected systems. Splitting the workload into smaller batches can sometimes avoid the failure, suggesting a workload-dependent edge case rather than a universal hardware fault.

One well-publicized community test sequence evaluated 21 different SSDs under a sustained-write stress test. Twelve of those drives exhibited the disappearance behavior. Most alarming: one model, reported as a Western Digital SA510 2 TB, could not be recovered in the tester’s environment. This chilling result underscores the potential for permanent data loss, not just temporary inconvenience.

Affected hardware: Phison in the spotlight, but not alone

The disappearing-drive phenomenon is not limited to a single brand or controller family. Japanese outlet NichePCGamer and X user @Necoru_cat compiled early lists of affected SSDs, which include:

  • Corsair Force MP600 (Phison E16 controller)
  • Phison PS5012-E12 (Phison E12 controller)
  • SanDisk Extreme Pro M.2 NVMe (Triton MP28 controller)
  • Fikwot FN955 (MAP1602 + WDS X3 9070 controllers)
  • Kioxia Exceria Plus G4 1 TB (Phison E31T controller)

While Phison controllers are overrepresented, the presence of non-Phison designs—notably the SanDisk drive—points to a host-firmware interaction rather than a simple hardware defect. A separate list of drives that become inaccessible during the failure but recover after a reboot includes:

  • WD Blue SN5000 2 TB (Polaris 3 controller)
  • WD Red SA500 2 TB SATA (Marvell 88SS1074)
  • Corsair MP510 960 GB (Phison PS5012-E12)
  • Crucial P3 Plus (Phison E21T)

This heterogeneity complicates easy attribution and suggests the root cause lies in how Windows’ storage stack interacts with a range of controller firmware during sustained write pressure.

Technical under the hood: two plausible mechanisms

Modern NVMe SSDs are complex embedded systems where the host OS, driver, controller firmware, and NAND management must coordinate precisely. Two leading hypotheses have emerged from public testing and historical precedent.

Host-driven NVMe command or buffering regression. A small change in Windows’ kernel, NVMe driver, or buffer-handling logic—for instance, in how the OS stages page-cache-backed writes and issues NVMe commands—can alter command ordering, DMA timing, or buffer lifetimes. If a controller receives commands or memory mappings in a cadence it cannot tolerate under heavy load, it may hang or become unresponsive, which the OS interprets as device removal. The observed unreadable telemetry and mid-write disappearance are consistent with a controller-level hang.

HMB / DRAM-less controller fragility and metadata pressure. Many cost-optimized SSDs are DRAM-less and rely on Host Memory Buffer (HMB) to borrow a portion of the system’s RAM for mapping tables and caching. Sustained sequential writes stress the drive’s flash translation layer (FTL) and mapping structures. Subtle changes in host-side HMB allocation or timing, or in the OS’s page-cache behavior, can surface race conditions and resource exhaustion in controller firmware. Earlier Windows 11 24H2 rollouts had already exposed HMB-related fragility on certain models, making this a plausible contributory factor again.

Both mechanisms are likely not mutually exclusive. Community data shows drives with specific Phison controller families are overrepresented, but isolated reports involving HDDs and non-Phison SSDs suggest the trigger is host-side behavior that exercises latent firmware bugs.

Vendor response: Phison steps forward, Microsoft stays quiet

Phison, whose controllers power many mainstream and budget NVMe drives, publicly acknowledged on its partner portal that it had been “recently made aware” of industry-wide effects tied to KB5063878 and the earlier preview update KB5062660. The company stated it is working with partners to identify potentially affected controller families and will distribute fixes through SSD brands rather than directly to consumers. This partner-first firmware distribution is standard, but it introduces a delay as each SSD vendor must validate patches against its own bill of materials and tooling.

Microsoft has not yet released a detailed technical breakdown. Industry expectations range from a Known Issue Rollback (KIR) that temporarily reverts the offending change, to a targeted hotfix, or a servicing block that prevents the update from installing on systems with affected hardware until firmware is updated. Given the severity—potential data loss—a rapid OS-side mitigation would be prudent.

Who is at risk and what to do now

Consumers and gamers using DRAM-less or HMB-reliant SSDs, especially cheaper M.2 NVMe models with Phison controllers, appear at elevated risk based on community reproductions. However, the issue is not strictly limited to those configurations. Power users who regularly perform large sequential writes—video editors, game library managers, disk cloners—are most likely to encounter the bug because their workflows match the trigger profile.

Enterprise IT departments should be especially cautious. The same update bundle also produced separate deployment problems (WSUS/SCCM error 0x80240069), requiring additional servicing controls. A phased rollout with representative hardware testing is essential.

Immediate mitigation steps

  1. Back up critical data now. Follow the 3-2-1 rule: three copies, on two different media, with one off-site. The primary risk is data loss during a write-induced failure.
  2. Avoid large sustained writes on any Windows 11 system that has installed KB5063878 or KB5062660. Split transfers into smaller chunks, and postpone write-heavy operations until a fix is available.
  3. Inventory your SSDs. Record model numbers, controller families (if known), firmware revisions, and whether the drive uses DRAM-less/HMB. This inventory will be crucial when vendor firmware updates arrive.
  4. Pause non-critical deployment of the August cumulative update in managed environments. Use ring-based deployment and wait for vendor advisories and Microsoft’s official guidance.
  5. Monitor vendor dashboards for firmware updates. SSD manufacturers will release patches through their support channels; do not apply firmware from untrusted sources.

Recovery prospects: reboot, firmware, or OS patch

In many community-reported cases, a reboot restored the drive’s visibility, though any data in flight during the event was likely corrupted. A minority of reports describe drives that remained inaccessible even after cold reboots, requiring vendor-specific recovery tools or deeper remediation. The extreme case of an unrecoverable drive underscores that immediate backups are non-negotiable.

Looking ahead, the fix landscape is likely to be twofold. SSD vendors will issue firmware updates that harden controllers against the new host command patterns. Microsoft may simultaneously issue a KIR or hotfix to revert the behavioral change in the storage stack. The combination of both is the most reliable long-term solution, as it addresses the root interaction rather than papering over one side.

A systemic reminder for the Windows hardware ecosystem

This incident is more than a single patch hiccup. It highlights a systemic fragility: OS updates are platform-level events that can expose latent firmware bugs across a broad, heterogeneous fleet. When host behavior changes—even subtly—controller firmware that previously operated within safe margins can crash. The consequences cascade from individual users to large enterprises, where a single unvalidated update can brick dozens of drives simultaneously.

The operational lessons are clear. Pre-release testing must include real-world heavy-write workloads on a diverse matrix of SSD controllers, especially DRAM-less designs using HMB. Synthetic benchmarks often miss the long-duration metadata and mapping stress that real applications generate. Faster, telemetry-driven collaboration between Microsoft and controller vendors would also shrink the window of exposure, converting weeks of guesswork into directed fixes.

For now, the guidance is simple and urgent: protect your data first, avoid heavy writes on patched systems, inventory your hardware, and await validated firmware or Microsoft mitigations before resuming normal write-intensive workflows. The KB5063878 storage regression is not a theoretical bug; it is a live data-integrity incident with real-world consequences.