Microsoft's August 12 cumulative update for Windows 11 24H2, KB5063878 (OS Build 26100.4946), is causing a subset of NVMe SSDs to suddenly vanish from the operating system during large sequential write operations, triggering data corruption and system instability, according to independent testers and hardware vendors. The issue, which affects drives from multiple brands using controllers from Phison and InnoGrit, has been reproduced by specialist outlets such as Tom's Hardware, Windows Central, and BleepingComputer, and Microsoft says it is actively investigating.
The Update and Its Fallout
Released as a combined servicing stack (SSU) and cumulative quality update (LCU), KB5063878 was intended to deliver security patches and reliability improvements. The official KB article initially made no mention of storage-device regressions. Within days, however, hobbyist labs and tech journalists began reporting that drives were disappearing mid-write. The pattern was consistent: during sustained, large sequential transfers—on the order of tens of gigabytes—the SSD would stop responding, vanish from File Explorer, Device Manager, and Disk Management, and in some cases, leave behind corrupted or truncated files. SMART telemetry and vendor diagnostic tools often became unreadable during the failure.
How Drives Vanish: The User Experience
The symptom profile collated from community reports and independent labs is stark:
- The drive simply disappears from Windows—no error prompt, no warning.
- Vendor utilities and SMART data stop responding or return garbled values.
- Files being written at the moment of failure are frequently damaged.
- A reboot usually restores visibility, but in a minority of cases, the drive remains inaccessible and may require reformatting or vendor intervention.
- Some users have reported bluescreens (BSODs) in related scenarios, particularly with certain Western Digital models that had prior issues with 24H2.
The randomness of the failure makes it especially treacherous: users may not notice until they attempt to open a recently saved file and find it corrupt.
A Specific Trigger: Heavy Sequential Writes
Reproductions zero in on a narrow set of conditions. The failures almost always occur during operations like installing large games (50 GB or more), copying multi-gigabyte archives, cloning drives, or writing massive backup images. Testers converged on a threshold of approximately 50 GB of continuous writes in a single operation. The risk increases noticeably when the target drive is more than 50–60% full—likely because the SLC cache and free block pool are already under stress, and the flash translation layer (FTL) must work harder to manage writes.
This behavioral fingerprint points to a host-to-controller interaction glitch exposed by the update, not a universal hardware defect. The regression only manifests when timing, caching, and device utilization align in a specific way.
Which SSDs Are Most Affected?
While no official, vendor-validated list exists, community collations and lab reproductions repeatedly cluster around certain controllers and models:
- Drives built on Phison controller families (various consumer models).
- Some DRAM-less NVMe designs that rely heavily on Host Memory Buffer (HMB) allocation.
- Specific product mentions include Corsair Force MP600, SanDisk Extreme Pro NVMe, Kioxia Exceria Plus G4, and assorted other consumer NVMe drives.
However, the evidence is provisional. Not every Phison-based drive fails, and isolated reports come from other controller vendors. Phison itself publicly repudiated a falsified “leaked” document that purported to list affected controllers and initiated legal action. The company stressed that only official statements should be considered authoritative and that it is coordinating with partners on the investigation.
Why an OS Update Can Break Your SSD
To understand how a software patch can cause a drive to vanish, it helps to remember that modern SSDs are co-engineered with the host operating system:
- The SSD controller firmware manages NAND operations, wear leveling, garbage collection, and the FTL.
- The host OS and NVMe driver define I/O timing, command queue depth, flush semantics, power management, and HMB allocation for DRAM-less drives.
- Firmware often relies on implicit timing and resource guarantees from the host; if the host changes how it allocates memory or issues write commands, latent bugs in the controller firmware can be triggered.
Under heavy sustained writes, an altered command timing or HMB behavior introduced by KB5063878 may push the controller into an unhandled state, causing a lockup. The mapping tables that translate logical blocks to physical NAND pages can become corrupted, making the drive appear blank or RAW. The community’s leading hypotheses—backed by reproducible test cases—center on:
- Host memory allocation and HMB interactions (especially critical for DRAM-less SSDs).
- Changes in flush requests or driver buffer handling that alter the write pressure.
- Elevated stress on SLC cache and FTL when the drive is already substantially filled.
Conclusive root cause, however, awaits telemetry correlation between Microsoft and the controller manufacturers.
Industry Response: Microsoft, Phison, and Others
Microsoft confirmed it is aware of customer reports and is investigating alongside storage partners. At the time of initial reporting, the company said its internal telemetry did not show a broad increase in disk failures or file corruption, hinting the issue may be conditional. The software giant has asked affected users to file detailed reports via the Feedback Hub or Support for Business to assist diagnostic collection.
Phison acknowledged it was “made aware of industry-wide effects” and is investigating. The controller firm also took the unusual step of publicly denying and threatening legal action over a falsified internal document that circulated online, calling it “completely fabricated.” Other vendors—Kioxia, Western Digital, and others—are tracking reports and preparing firmware advisories where appropriate.
Independent outlets played a crucial role in elevating scattered forum anecdotes to an industry-level investigation. By reproducing the failure with consistent steps and documenting the ~50 GB write threshold and capacity sensitivity, they gave both Microsoft and the controller makers a repeatable test case.
Immediate Actions for Users and IT Admins
Until a validated fix is released, the following precautions are strongly advised:
1. Back up immediately. A verified, separate backup is the single most important defense. Prioritize machines that have installed the August 2025 cumulative updates.
2. Avoid heavy sequential writes on updated systems. Postpone tasks like large game installs, massive file copies, cloning, or archive extractions.
3. For managed fleets: Stage the update in test rings that include representative storage hardware and heavy-write workloads. Do not push KB5063878 to production without validation.
4. Check for vendor firmware updates. If an SSD manufacturer issues a firmware update specifically addressing interactions with Windows updates, apply it using the vendor’s recommended tool.
5. If a drive vanishes: Stop all writes, power off the system immediately to prevent further corruption, and consider forensic imaging before attempting recovery.
For mission-critical systems, postpone the update entirely until a validated remediation is available.
Forensics and Recovery After a Failure
If an incident occurs, follow these steps to maximize recovery chances and assist the investigation:
- Power off the machine. Further writes can irreversibly corrupt metadata.
- For critical data, remove the drive and create a sector-level image using a hardware write-blocker and forensic tools. Preserve the original drive for vendor diagnostics.
- Collect system logs (Event Viewer, disk errors), Windows Update history, and note the exact KB numbers and build. This information is vital for telemetry.
- Contact the drive manufacturer’s support, share the image and logs, and follow their diagnostic and firmware reflash instructions.
- If in-house forensic capability is lacking, consult a professional data recovery service. Early, non-destructive imaging significantly improves success rates.
Evaluating the Evidence
The strength of the evidence lies in independent, repeatable reproductions. Multiple outlets and hobbyist labs arrived at the same workload and symptom profile, which is why vendors and Microsoft are treating the matter seriously. Phison’s acknowledgment adds further weight.
Shortcomings remain. No vendor-validated list of affected drives exists; early community compilations are investigative leads, not confirmed blacklists. Microsoft’s own telemetry did not initially detect the issue at scale, suggesting it may be rare or conditional. The falsified document episode also injected noise into the community conversation. Until official advisories are published, users and admins must balance caution with pragmatism.
Broader Implications for PC Reliability
The incident underscores three enduring truths about modern computing:
- The storage stack is co-engineered. OS, driver, firmware, and UEFI must all play in harmony. A minor host-side change can expose a dormant firmware bug.
- Stress testing must reflect real-world loads. Standard functional tests can miss regressions that only appear under sustained heavy writes and high drive utilization.
- Backups and staged rollouts are non-negotiable. When low-level metadata is at risk, diligent backup practices and conservative deployment are the only sure safeguards.
What to Watch For
Monitor the following channels for updates:
- Microsoft’s release-health dashboard and the official KB5063878 article for any Known Issue Rollback (KIR) or mitigation.
- Firmware advisories from Phison, InnoGrit, and consumer SSD brands (Corsair, SanDisk, Kioxia, etc.).
- Consolidated lab reports that pinpoint the exact controller families, firmware revisions, and host conditions that reproduce the failure.
- Any emergency patch or consumer advisory from Microsoft that addresses the storage regression directly.
At the time of writing, the investigation remains active. Users should avoid speculative “one-size-fits-all” remedies and follow only official guidance.
The Bottom Line
The August 2025 patch for Windows 11 24H2 introduced a genuine, reproducible storage regression that can cause NVMe drives to vanish during heavy writes, with a real risk of data loss. Independent verification, vendor acknowledgments, and Microsoft’s ongoing investigation confirm the problem’s legitimacy. For now, the most prudent course is to back up immediately, defer large sequential writes, stage updates in test environments, and keep a close eye on official firmware and OS fixes. This episode is a sobering reminder that even routine cumulative updates can shake the delicate co-engineering of modern PCs—and that disciplined backup and testing regimens remain the ultimate insurance against such surprises.