Phison is actively investigating a storage regression in Windows 11's August 2025 cumulative update that causes NVMe SSDs to vanish mid-transfer, while simultaneously denouncing a falsified internal document designed to pin the blame solely on its controllers.

The update, identified as KB5063878 (OS Build 26100.4946), shipped on August 12, 2025. Within 72 hours, hobbyist testers and enthusiast outlets reproduced a clear failure profile: under sustained, large sequential writes—often exceeding 50 GB on drives filled to around 60%—some NVMe drives stop responding. They disappear from File Explorer, Device Manager, and Disk Management. In a troubling subset of cases, drives remain inaccessible or return as corrupted after a reboot.

The Failure Fingerprint

Independent labs and community testers ran systematic write-stress experiments across multiple drives. The most repeatable trigger was a heavy sequential write workload on moderately full SSDs. Exactly at the point where SLC caching exhausts, mapping-table updates intensify, and host memory buffer (HMB) pressure peaks, the drive drops offline.

During the incident, SMART and NVMe telemetry become unreadable—pointing to a controller-level hang rather than a simple filesystem fault. A Japanese enthusiast’s detailed tests, widely shared on X, showed that out of 21 drives tested, 12 became inaccessible during sustained copies. One drive, a Western Digital SA510 2TB, could not be recovered at all, even after multiple power cycles.

The tests included copying a large game library folder, preparing compressed archives, and then expanding them onto the target drive. The most commonly cited real-world trigger was updating or moving games like Cyberpunk 2077 or Honkai: Star Rail—operations that routinely exceed 50 GB of sequential writes.

Timeline of Events

  • August 12, 2025 — Microsoft publishes KB5063878. The public KB article lists no storage-related regressions.
  • 48–72 hours later — Hobbyist testers and tech outlets replicate the failure profile. Community posts become the primary early signal.
  • Mid‑ to late‑August — Phison issues a statement to Tom’s Hardware, acknowledging “industry-wide effects” associated with KB5063878 and KB5062660. The company confirms it is working with partners to identify affected controllers and provide remediation.
  • Concurrently — A document styled as an internal Phison advisory begins circulating. It lists specific controllers, uses alarmist language about “permanent data loss,” and claims the issue is exclusive to Phison. Phison immediately disowns it and announces legal steps.
  • Ongoing — Microsoft, Phison, and SSD vendors collect telemetry and coordinate forensic testing. Firmware advisories and targeted mitigations are under preparation.

The Falsified Document

The circulated document posed as an official Phison advisory. It named controller families such as PS5012-E12 and later E21T/E31T variants, cited anecdotal community reports as confirmed data, and warned that only Microsoft could remedy the situation—leaving Phison customers with no recourse.

Phison categorically denied the document’s authenticity. “That document is falsified and is not from Phison,” the company stated, adding that it is pursuing appropriate legal remedies. While the specific legal mechanisms were not detailed in public filings at press time, the move underscores the seriousness with which Phison views the matter.

Falsified technical documents pose multiple risks in a multi-vendor incident:
- Misdirected blame can skew partner and customer triage, delaying the cross-industry cooperation needed for a fix.
- Unnecessary panic may spike RMA volumes, overload support channels, or trigger premature recalls.
- Legal and commercial exposure can arise from contractual disputes, retail delistings, or investor reactions based on incorrect information.
- Forensic confusion can occur if vendors respond to unauthenticated materials, potentially contaminating the evidence trail.

Phison’s public rejection of the fake document is a critical step in preserving the integrity of the investigation. In an incident where coordinated telemetry and joint forensic logs are the truth source, authenticated communication becomes paramount.

Technical Anatomy: Why a Windows Update Exposes SSD Fragility

Modern NVMe SSDs are deeply co‑engineered systems. Controller firmware, optional DRAM, NAND channel management, and host-side drivers all interact through complex interfaces. A small change in command ordering, buffer allocation, or memory‑lending behavior can expose latent firmware edge cases.

Two plausible mechanisms align with the observed failure fingerprint:

Host Memory Buffer (HMB) and DRAM-less Designs

Many cost-optimized SSDs omit dedicated DRAM and instead borrow a portion of system memory via HMB to store logical‑to‑physical address tables. If KB5063878 altered the timing, allocation size, or lifetime semantics of HMB operations, it could introduce race conditions or resource assumption violations in controller firmware. Under heavy metadata update loads—precisely the kind that accompany large sequential writes—the controller may lock up entirely.

Sustained Sequential-Write Stress and Controller State

Long continuous writes stress mapping-table updates, SLC caching behavior, garbage collection, and background metadata flushes. A host-side change in how flushes are issued, commands are ordered, or DMA buffers are managed can create an unusual command cadence that the firmware was never engineered to handle. The fact that SMART telemetry becomes unreadable during an incident strongly supports a controller-level hang.

These mechanisms explain why the same workload does not consistently fail across all drives with identical controllers. Firmware revisions, drive fill levels, motherboard UEFI, NVMe driver versions, and even PCIe signal quality can determine whether a particular drive crosses the fault threshold. Early community lists pointed to Phison-based designs, but several non-Phison models also exhibited problems in isolated tests, confirming an industry-wide host-to-controller interaction rather than a single-vendor bug.

Affected Hardware and Symptom Levels

Community-sourced lists frequently name drives using Phison E12, E21T, and E31T controllers, appearing under brands such as Corsair, SanDisk, Kioxia, and various third-party labels. However, not every drive with a listed controller failed, and the Western Digital SA510 (which uses a non-Phison controller) suffered the most severe outcome. These lists are best treated as investigative leads, not definitive blacklists.

Symptom levels observed in community reproductions:
- NG Lv.0 — No issue under test.
- NG Lv.1 — Drive disappears mid-write but recovers after reboot; some files may be truncated.
- NG Lv.2 — Drive remains inaccessible after reboot; partition may appear as RAW or data corrupted; requires vendor intervention or RMA.

Real-world triggers include large game downloads or updates (Cyberpunk 2077, Honkai: Star Rail), extraction of multi‑gigabyte archives, and disk cloning operations. Splitting transfers into smaller chunks—well below the ~50 GB threshold—often avoids the failure, reinforcing the sustained-write trigger hypothesis.

Vendor and Microsoft Responses

Phison told Tom’s Hardware: “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. We understand the disruption this may have caused and promptly engaged industry stakeholders.” The company confirmed that affected controllers are under review and that it is working with partners to provide advisories and remediation. Simultaneously, Phison issued a forceful denial of the falsified document and signaled legal steps.

Microsoft has not yet publicly detailed a fix in a KB article, but it has acknowledged the reports and is investigating with partners. Historically, Microsoft addresses such regressions using Known Issue Rollback (KIR) or targeted hotfixes if host behavior is implicated. Industry observers expect a formal update to the KB5063878 documentation or a separate out-of-band fix once root cause is confirmed.

SSD vendors are the primary channel for firmware-based remediation. Phison supplies controller firmware to drive manufacturers, who then test and distribute updates via their own tools. Coordinated firmware updates—tailored to specific SKUs—are likely to roll out in stages once joint testing completes.

Immediate Guidance for Users and IT Teams

Until official fixes ship, conservative triage reduces data-loss exposure:

  • Back up immediately. Follow the 3‑2‑1 rule: three copies, on two different media, one offsite. Backups are the only reliable defense against low-level metadata corruption.
  • Avoid heavy, sustained writes on recently updated systems. Postpone large game installs, archive extractions, cloning, or mass media transfers.
  • Split large transfers into chunks well below 50 GB, and monitor drive behavior with vendor utilities.
  • Inventory drives. Use tools like CrystalDiskInfo to identify controllers and firmware versions. Check vendor advisory pages before flashing firmware.
  • For administrators: Stage KB5063878 on representative hardware fleets before broad deployment. Hold updates on production systems until validated mitigations are available.
  • If a drive disappears during a write:
  • Stop writing immediately.
  • Capture Event Viewer NVMe/storage error logs.
  • Do not attempt unsafe firmware flashes without vendor guidance.
  • Contact the SSD vendor’s support with logs and exact firmware/drive details.

Forensic Needs: What Will Resolve Root Cause

Definitive root cause requires instrumented, joint analysis from Microsoft, controller vendors, and drive integrators. Essential data points include:

  • Controller-side secure trace logs and firmware dumps from Phison firmware.
  • Host-side traces: Event Viewer, NVMe driver traces, DMA timing, and HMB allocation records.
  • Cross-correlation between affected and unaffected drives sharing identical firmware and platform to isolate variables.
  • Controlled lab reproductions spanning UEFI/BIOS versions, power-management states, driver stacks, and storage fill levels.

Only this level of coordinated telemetry can distinguish between an OS‑side issue (fixable via KIR), a firmware defect (requiring controller patches), or a combination of both. Partial or anecdotal analysis risks misattribution and delayed remediation.

Broader Implications and Long-Term Lessons

This incident is not the first OS update to surface storage fragility, but its fallout underscores several systemic gaps:

  • For buyers and IT: Demand validated compatibility matrices and representative test rings from vendors. Prefer drives with robust update mechanisms and strong telemetry for enterprise fleets. Always stage OS updates.
  • For vendors and platform maintainers: Pre-release testing must include heavy, long-duration sequential workloads across a broader hardware matrix, especially DRAM‑less designs and varied HMB behaviors. The falsified document episode shows that transparent, authenticated communication is as critical as technical fixes.
  • For the industry: There is no formal body that certifies major OS updates against the hundreds of SSD firmware variants in the field. Improved vendor cooperation, shared testbeds, and perhaps a standard for storage-stack regression testing pre-release could close this gap.

Conclusion

The KB5063878 update introduced a reproducible storage regression that can render some NVMe SSDs inaccessible during sustained heavy writes. Community testing rapidly surfaced the failure profile, and Phison has stepped forward to investigate while forcefully repudiating a forged document that sought to exploit the incident. The immediate path forward is clear: back up data, avoid large write workloads on affected systems, and await coordinated firmware or OS mitigations from Microsoft and SSD manufacturers. Behind the scenes, a cross-industry forensic effort is underway—one that, if properly resourced, will not only fix this regression but also strengthen the governance of host-to-storage interactions for years to come.