Microsoft’s August 12, 2025 cumulative update for Windows 11 24H2 (KB5063878, OS Build 26100.4946) is at the center of an escalating storage crisis. Multiple independent testers and specialist hardware outlets have reproduced a failure pattern where certain NVMe and SATA SSDs vanish from the operating system during sustained heavy write activity. In a minority of cases, the drives return with corrupted or inaccessible data, even after a reboot. Controller designer Phison confirmed it is investigating the “industry-wide effects” of the update alongside Microsoft and other partners, while the official KB article initially stated Microsoft was “not currently aware of any issues.”

This is not routine update teething. The symptoms are severe: drives disappear mid-transfer, SMART telemetry goes dark, and some devices never recover without low‑level reflashing or RMA. Early community tests converged on a clear trigger—continuous sequential writes of roughly 50 GB or more, especially on drives already over 60% full. The reproduction is consistent enough that Tom’s Hardware, BleepingComputer, and others have validated the pattern, moving the incident from forum anecdote to confirmed regression.

What the Update Delivered — and What It Broke

KB5063878 was shipped as the regular monthly quality and security LCU for Windows 11 version 24H2. Microsoft’s public KB note described it as providing “security and quality improvements” with no known issues at launch. The update superseded KB5062660 (an earlier cumulative) and brought the OS build to 26100.4946. While most systems absorbed the patch without incident, a subset of storage configurations immediately exhibited catastrophic I/O failures.

The failure signature is unmistakable: a user initiates a large file copy, game update, or archive extraction, and suddenly the target drive disappears from File Explorer, Device Manager, and Disk Management. SMART data becomes unreadable. The copy dialog freezes, then throws an I/O error. A reboot often brings the drive back, but the files being written are corrupted; in rarer cases, the partition table is damaged, showing as RAW and demanding professional recovery.

Community analysis points to a change in host‑side buffering or write‑back behavior introduced by the update. This altered timing appears to push SSD controllers—particularly those under heavy garbage‑collection load when the drive is already partially full—into an unrecoverable hang state. The controller stops responding to NVMe or SATA commands, causing the OS to treat the device as removed.

Symptoms and Trigger Profile

The most consistent trigger is a sustained, sequential write of 50 GB or more in a single operation. Testers reported that splitting the same data into smaller chunks or throttling the copy speed often avoided the failure. Drives with less than 40% free space were markedly more vulnerable, likely because the effective SLC cache shrinks, forcing the flash translation layer (FTL) to juggle writes, reads, and background garbage collection simultaneously. This increases write amplification and controller load, right when the host is flooding the queue with buffered data.

Core symptoms:
- Drive becomes unresponsive mid‑write and vanishes from the OS.
- SMART and vendor telemetry inaccessible or garbled.
- File operations hang; event logs fill with I/O errors.
- Reboot restores visibility for most drives, but recently written data is lost.
- In severe cases, the partition shows as RAW and cannot be mounted without data‑destructive recovery attempts.

These symptoms have been observed on a range of NVMe and SATA drives. Early reports named models with Phison PS5012‑E12 controllers (and related families) disproportionately, but drives from other controller vendors—including Western Digital, SK hynix, ADATA, and Crucial—appear in test logs. Sample models: WD Blue SN5000, Corsair MP600/MP510, Crucial P3 Plus, SK hynix Platinum P41, ADATA LEGEND 800, XPG SX8200 Pro. Crucially, not every unit of a given model fails; firmware revision, NAND configuration, host chipset, BIOS version, and free space all modify the risk. Labeling an entire brand as “affected” is premature.

Technical Hypothesis: A Host‑Controller Clash

While a final root cause requires combined telemetry from Microsoft and SSD vendors, the community has coalesced around a plausible chain of events. The theory holds that KB5063878 modified the way Windows buffers writes and sends flush/FUA commands, possibly to improve performance or security. Under light workloads, the change is harmless. But when a large sequential write saturates the command queue, the OS holds an unusually large amount of data before forcing a flush. On a drive with reduced spare area, the controller is already doing extensive garbage collection. The flood of buffered write commands, combined with the controller’s internal work, drives the device into a stall or hang.

When the controller stops responding, the NVMe stack sees a command timeout. The PCIe device may be removed from the bus. File‑system metadata updates that were in‑flight—updates to the NTFS MFT, directory entries, or partition structures—are left half‑written. The result is data corruption that persists across reboots because the on‑media state is broken.

Phison’s statement supports this direction. By acknowledging the update’s “industry‑wide effects” and initiating a controller‑level review, the company implicitly confirms that the issue lies in a host‑to‑controller interaction, not in a simple driver bug. A fix will likely involve firmware patches that make the controller more resilient to sudden queue‑depth surges, as well as possible OS‑side tweaks to cap I/O pressure when drives signal congestion.

Timeline and Official Responses

August 12, 2025 – Microsoft released KB5063878 (OS Build 26100.4946). The public KB listed no known storage issues.

Within days – Community testers, notably the X user Nekorusukii, reproduced the drive‑disappearance pattern and published detailed logs. The Japanese outlet NichePCGamer aggregated reports from eight other users with similar experiences.

Mid‑August – Tom’s Hardware and BleepingComputer validated the reproductions in their own labs. Phison issued a statement: “Phison has recently been made aware of the industry‑wide effects of the ‘KB5063878’ and ‘KB5062660’ updates on Windows 11 that potentially impacted several storage devices, including some supported by Phison. … the controllers that may have been affected are under review and we are working with partners.”

Subsequent days – Microsoft updated its stance from “not aware of issues” to “investigating reports and working with partners.” The company also addressed a separate installation error (0x80240069) that affected WSUS/SCCM deployment of the same package, resolved via Known Issue Rollback (KIR). That fix was unrelated to the storage regression but highlighted the patch’s broader fragility.

Practical Impact: Two Recovery Scenarios

User and tester reports describe two outcomes, which shape the immediate advice:

  1. Mild outcome (most common) – The drive vanishes mid‑write but reappears after a reboot. SMART becomes readable again. Data in transit at the moment of failure is corrupt, but the drive is otherwise usable. Users can resume normal operation, though the bug may recur during the next heavy write.
  2. Severe outcome (minority) – The drive does not return cleanly. Partitions show as RAW. SMART data is unreadable, and the BIOS may intermittently fail to detect the device. Recovery has required rewriting partition tables (TestDisk, Linux fdisk), a full media erase via blkdiscard or vendor tools, or even an RMA to reflash firmware. In all severe cases, user data written during the incident is lost.

Crucially, uninstalling KB5063878 after on‑disk damage has occurred does not repair corrupted metadata. The damage is on the media itself, so removing the host‑side patch is a preventive measure, not a cure.

For Individual Users

  • Back up immediately. If you haven’t recently backed up, do it now before any large write operation. Backups are the only reliable protection against corruption.
  • Check your build. Go to Settings > System > About. If you’re on OS Build 26100.4946 (KB5063878), you are vulnerable.
  • Avoid large sequential writes. Postpone game updates, disk imaging, mass file copies, and archive extractions until vendors publish validated firmware or Microsoft releases a fix. If unavoidable, split transfers into chunks smaller than 50 GB and monitor the drive.

If a Drive Disappears

  • Stop all writes immediately. Shut down the application or process that triggered the transfer.
  • Reboot. In most cases, the drive will reappear. Immediately run your SSD vendor’s diagnostic tool to capture SMART logs and controller telemetry—this will be critical for support cases.
  • If the drive remains RAW or invisible, do not reformat. Image the raw device (using dd or vendor imaging tools) if you need to attempt data recovery, then contact the SSD manufacturer’s support for RMA or firmware reflash guidance.

For IT Administrators

  • Stage deployments. If you manage fleets, test KB5063878 on a representative set of hardware that includes the exact SSD models used in production, especially those with Phison controllers.
  • Suspend large automated write jobs (imaging, patch deployment, content synchronization) on recently updated machines until the situation stabilizes.
  • Monitor official channels. Watch Microsoft’s release health dashboard and your SSD vendor’s advisory page. When firmware updates arrive, deploy them through validated management tools only after testing.
  • Leverage KIR if necessary. For enterprise deployments, Microsoft’s Known Issue Rollback can temporarily disable problematic code changes without uninstalling the entire update. Follow the guidance in KB5063878’s support article if your organization uses WSUS or SCCM.

What Remediation Will Likely Involve

History suggests a dual‑pronged fix:

  1. SSD firmware updates – Controller vendors (starting with Phison, given its acknowledgment) will release firmware that adjusts internal command‑queue handling, timeout thresholds, or power‑state transitions to tolerate the new host‑side behavior. These updates will be distributed through drive‑brand partners (Crucial, Corsair, WD, etc.) via their support pages and utilities.
  2. Microsoft OS patches – If telemetry confirms that the host is generating unsafe I/O patterns, Microsoft may release a supplemental update that throttles queue depth or delays I/O completion when certain drive families are detected. In extreme cases, the company could issue a targeted rollback of the storage stack changes.

Phison’s public commitment to “continue to provide updates and advisories to partners” signals that the firmware route is already underway. Enterprise and consumer deployment of those updates will follow rigorous validation cycles, so patience is required.

Strengths and Limitations of the Current Evidence

The evidence is strong enough to warrant immediate caution. The reproducibility across multiple independent test benches—with consistent triggers and symptoms—elevates this beyond random hardware failure. Phison’s acknowledgement and Microsoft’s shift from “no known issues” to “investigating” add official weight.

However, open questions remain:
- Microsoft has not published a root‑cause analysis or assigned a specific KB article to the storage regression. The initial KB page still underplays the problem.
- Community model lists are heterogeneous; a drive that fails in one test bench may pass in another due to firmware, capacity, or host variables. No official list of affected drives exists.
- Some skeptics argue that spontaneous SSD failures are common and that the update is coincidental. But the clustering around a specific workload pattern and the rapid disappearance/reappearance cycle strongly suggest a software‑induced interaction.
- The exact host‑stack change in KB5063878 remains unknown. Without Microsoft’s disclosure, the community hypothesis—while coherent—is not confirmed.

Long‑Term Lessons for the Windows Ecosystem

This incident reinforces three hard truths about modern PC storage:

  • Storage is a co‑engineered system. The OS, driver, firmware, and hardware are deeply intertwined. A small timing or buffering change in a cumulative update can expose latent firmware bugs that remained dormant for years.
  • Backups are non‑negotiable. When metadata is at risk, no software uninstall can save your data. A reliable, offline backup strategy is the only safety net.
  • Rollouts demand realism. Enterprises must test updates on the exact storage hardware they use, under workloads that mimic production. A single missed edge case in test rings can cause fleet‑wide disruptions.

As the investigation unfolds, the Windows community would do well to watch official channels and resist the urge to draw sweeping conclusions from early model lists. The fix will come, but it will arrive through a methodical, co‑engineered process that starts with controller logs and ends with firmware updates. Until then, back up your files and treat heavy writes with extreme care.