Microsoft’s August 2025 cumulative update for Windows 11 is causing a pocket of storage devices to clinically fail during heavy write operations, according to a growing collection of community testers and independent labs. The KB5063878 patch—a combined servicing stack and cumulative update for version 24H2—triggers some solid-state drives to abruptly disappear from the operating system when they are subjected to sustained sequential writes of roughly 50 GB or more. In a subset of cases, drives remain unrecoverable even after a full power cycle, leaving users with corrupted files, truncated data, and potential total data loss.

Controller vendor Phison publicly acknowledged the issue on August 19, telling Tom’s Hardware it was investigating “industry-wide effects” of the updates and had “promptly engaged industry stakeholders.” Microsoft followed suit, stating it was aware of the reports and working with partners to diagnose the problem. The coordinated response, paired with detailed forensic work by community researchers, has elevated the situation from scattered forum anecdotes to a focused industry investigation.

The trigger: a 50 GB write threshold on stressed drives

The failure signature is remarkably consistent across independent reproductions. Users trigger the bug by initiating a single, large sequential write—whether copying a game folder of tens of gigabytes, extracting a compressed archive, or cloning a disk image. The operation runs normally for a while, then hits a wall: the target SSD vanishes from File Explorer, Disk Management, and Device Manager simultaneously, as if physically unplugged. Files being written at that moment are almost always corrupted or truncated.

In tests conducted by Japanese researcher @Necoru_cat and others, the critical threshold clustered around 50 GB of continuous writes on drives that were more than 60 percent full. The specific reproduction method involved copying a Cyberpunk 2077 Steam library folder, compressing it, and then writing the expanded archive to the SSD under test. Out of 21 drives tested, 12 became inaccessible—including units from multiple brands and controller families. One drive, a Western Digital SA510 2 TB, could not be recovered even after a reboot. The remaining 11 reappeared after a restart but remained vulnerable to the same failure if another large write was attempted.

The problem is workload-specific: ordinary desktop use rarely triggers it. But for anyone who keeps large game libraries, edits high-resolution video, or runs disk imaging utilities, the risk is immediate and real.

Which hardware is affected? Not just Phison DRAM-less SSDs

Early speculation pinned the bug on DRAM-less SSDs using Phison controllers, but community testing paints a broader picture. The 12 drives that disappeared in @Necoru_cat’s test included models with controllers from multiple vendors, not just Phison. Isolated reports also mentioned spinning hard drives, though the overwhelming focus remains on consumer NVMe SSDs.

Phison has confirmed it is reviewing which of its controller families may be involved and is working with partners. Several SSD OEMs have begun releasing firmware updates or advisories. However, the attack surface is nuanced: the vulnerability depends not just on the controller chip but on the specific firmware build, the platform’s BIOS/UEFI version, and the drive’s fill level. This makes crowdsourced lists of affected models—while helpful as investigative leads—inherently provisional.

The situation grew more confusing on August 19 when a document circulated online that purported to be an internal Phison advisory listing impacted controllers. Phison quickly denounced the document as falsified and pursued legal action to stop its spread, urging users to rely only on official vendor communications. The incident underscores the noise that can cloud a real, high-stakes hardware issue.

Vendor reactions: investigations, firmware drops, and a fake leak

Microsoft’s initial posture was cautious. The company said its internal telemetry had not detected a broad spike in disk failures and asked affected customers to report via Support and the Feedback Hub. That gap between community observations and vendor-scale telemetry is common: a highly specific trigger condition can affect a small but real subset of devices without moving aggregate reliability metrics.

Phison, meanwhile, took a more assertive public stance. Its statement acknowledged the disruption, committed to providing “applicable remediation,” and emphasized ongoing coordination with Microsoft and OEMs. The company’s rapid legal move against the fake document signals just how sensitive the dialogue between controller makers and OS vendors has become.

On the ground, SSD manufacturers are already shipping patches. Firmware updates that adjust Host Memory Buffer (HMB) behavior or command handling have appeared for select models from major brands. Independent testers report mixed results: some drives regain stability after flashing, while others still succumb to the write glitch, suggesting that firmware alone may not be a universal cure.

How the bug disrupts SSDs: a technical hypothesis

Modern SSDs operate as co-engineered systems where the OS storage driver, PCIe/NVMe stack, controller firmware, and NAND flash management all interact in tight lockstep. A subtle host-side change—an altered HMB allocation pattern, a shift in write-cache flush timing, or a modification to power management commands—can push a controller into an untested corner case that was never triggered before.

Observables from the field point to a controller firmware lock-up rather than simple filesystem corruption. When the failure occurs, SMART attributes and vendor health telemetry often become unreadable, which indicates the controller has stopped processing host commands entirely. The 50 GB threshold also aligns with the point where SLC caches typically run out on consumer drives, forcing the controller into a direct-to-TLC/QLC write mode that stresses metadata tables, garbage collection, and buffer management. On already-filled drives, the reduced overprovisioned space amplifies that stress, making failure more likely.

A definitive root cause requires low-level vendor telemetry and coordinated forensic analysis—exactly the work Microsoft and Phison are undertaking. Until they publish a post-mortem, these remain informed hypotheses, not settled science.

Protect your data now: immediate steps for Windows users

The most urgent action is backing up irreplaceable files to a separate physical drive or cloud storage. This is not a drill: the combination of a transient drive disappearance and an active write operation can corrupt files and leave the file system in an inconsistent state.

After securing a backup, avoid single-session writes larger than 20–30 GB to any drive that has received the August 2025 updates. If you must transfer a large dataset, break it into smaller batches and monitor the drive’s behavior between them. For enterprise environments or power users who rely on heavy sequential writes, consider pausing the KB5063878 deployment via the “Pause updates” control or Windows Update for Business policies until a fix is validated.

Keep automatic Windows Update enabled for remediation purposes—the eventual fix will likely arrive as another cumulative patch. SSD firmware updates should be applied only after you have a verified backup and after reading the vendor’s official advisory for your exact model and firmware revision. Flashing a drive without a backup in a volatile situation multiplies risk.

When drives don’t come back: recovery options

If an SSD disappears mid-write, stop using it immediately. Power down the system completely—a cold boot—and then restart. Many drives rematerialize after a full power cycle. Once visible, copy all readable data to safe storage before attempting any repair.

For drives that remain inaccessible, do not repeatedly reboot, format, or attempt in-place repairs. Those actions can overwrite recoverable metadata. Document the drive’s exact model, firmware version, and the Windows build and KB number, then contact the SSD vendor’s support channel. In severe cases, professional data recovery services may be needed, especially if the partition table or critical file system structures have been damaged.

If a firmware update is available and the vendor specifically recommends it for this issue, follow the official procedure—but only after creating a sector-level forensic image of the drive if the data is critical and recovery budget allows.

Implications for Windows update reliability

This incident is not the first time a routine security patch has exposed low-level storage issues, but its reproducible nature and the involvement of multiple controller families make it a standout event. It highlights a growing fragility in the PC storage stack, where OS updates interact with millions of lines of firmware code written by dozens of controller vendors, each tuned to specific host behaviors.

For Microsoft, the episode reinforces the value of staged rollouts and the inclusion of diverse storage hardware in Insider testing rings. It also underscores the need for stronger telemetry taps that can detect controller-level hangs before they become widespread user-facing failures. For IT teams, it is a reminder that update testing must simulate real-world workloads—not just boot-and-ping smoke tests—to catch corner-case regressions.

What happens next

The next authoritative milestones will likely be a Microsoft Release Health dashboard entry for KB5063878, a formal root-cause analysis from Phison, and a wave of validated SSD firmware revisions targeting the specific command sequences that trigger the lock-up. Community testers and outlets will continue to publish reproduction results, which will help validate the effectiveness of fixes.

Until those pieces fall into place, the prudent advice remains unchanged: back up critical data immediately, steer clear of heavy sequential writes on vulnerable drives, and keep a close eye on official channels from Microsoft and your SSD manufacturer. This is a live, high-stakes investigation where the difference between a minor inconvenience and permanent data loss is a few simple precautions taken early.