Phison, the SSD controller giant, acknowledged it is investigating widespread reports that Microsoft’s mid‑August Windows 11 cumulative update (KB5063878 / OS Build 26100.4946) can cause NVMe solid‑state drives to abruptly disappear during sustained heavy writes. The issue, which multiple independent testers have reproduced, typically strikes after around 50 GB of continuous sequential writes on moderately filled drives. Phison says it is coordinating with Microsoft and storage partners to identify affected controllers and deliver fixes, while warning users to treat a forged internal advisory circulating online as fraudulent.

Microsoft shipped KB5063878 and the related preview update KB5062660 in August 2025. Within days, enthusiasts and specialist outlets began documenting a consistent failure: NVMe SSDs vanish from File Explorer, Device Manager, and vendor management utilities mid‑write. Drives sometimes return after a reboot, but in a minority of cases they remain inaccessible – requiring firmware reflashes or RMA. Files being written are frequently truncated or corrupted, and partitions may flip to RAW.

“This is not a random bricking event; it’s a reproducible stress scenario that can be pinned down and investigated,” said a lead tester at a well‑known hardware forum, who asked not to be named. “That reproducibility is what makes it actionable.”

What Users Are Seeing: Symptom Profile and Reproducibility

The hallmark of the regression is sudden, silent disappearance. Users report that during large game installs, archive extractions, or disk cloning, the target NVMe drive simply ceases to respond. The drive vanishes from all OS interfaces; vendor utilities cannot read SMART telemetry; and Windows Event Viewer may show bus reset or surprise removal errors. In about 10‑15% of cases, the drive does not return after a normal restart, requiring physical power cycling or specialized recovery tools.

Reproducers in community labs have honed a narrow, realistic workload that triggers the bug:

  • The drive is approximately 50–60% full – enough to exercise the flash translation layer but not so full that write amplification or garbage collection dominates.
  • A sustained sequential write operation, such as copying a single 60 GB file or decompressing a large archive, is performed.
  • The failure often occurs after roughly 50 GB of continuous writes, though the threshold varies with drive model and firmware revision.

One tester described the moment: “It’s like pulling the plug. One second the copy dialog is chugging along, the next the progress bar freezes and the drive is just gone.”

Why This Points to a Host‑Controller Interaction Glitch

Modern NVMe SSDs are tightly coupled systems. The operating system’s storage stack, the PCIe link, controller firmware, NAND media, and optional DRAM or Host Memory Buffer (HMB) all interact in real time. The observed failure mode – controller unresponsiveness while a write is in flight, combined with unreadable telemetry – strongly suggests a firmware‑level hang, not a simple filesystem bug.

Two technically plausible, non‑exclusive root causes have emerged from forensic hypotheses and public reporting:

  1. Host‑side behavior change in the Windows storage stack. A kernel or driver update might alter DMA timing, NVMe command ordering, or buffer allocations. If Microsoft’s update changed HMB allocation cadence or the size of memory regions offered to the drive, controllers that previously operated within safe timing windows could now encounter race conditions.

  2. Latent firmware edge cases in DRAM‑less, HMB‑dependent controllers. Many budget SSDs lack an on‑board DRAM cache and instead rely on the NVMe Host Memory Buffer to store mapping tables. HMB makes the drive acutely sensitive to how the host allocates, sizes, and manages that memory. A subtle timing change in the host can expose firmware race conditions or resource exhaustion bugs that have lain dormant for years.

Community reproductions disproportionately involve DRAM‑less designs built around Phison’s E13T, E18, and E21T controllers, though other controller families have also generated isolated reports. This clustering aligns with the HMB hypothesis, but both mechanisms could be at play depending on the specific drive.

Affected Hardware: Models, Controllers, and Caveats

Early community collations and lab tests show clustering around drives that use Phison controllers and DRAM‑less architectures. Branded models repeatedly appearing in test lists include select SKUs from Corsair (Force Series MP510, MP600), Kioxia (Exceria and BG4 series), SanDisk (Extreme Pro M.2), and a range of third‑party modules carrying Phison reference designs. However, the phenomenon is not strictly limited to Phison: a handful of non‑Phison drives and even isolated HDD reports have surfaced.

Crucial caveats temper these initial leads:

  • Firmware revision matters immensely. Two identical SSDs with different factory firmware can behave completely differently under the same update.
  • Platform variables influence reproducibility. Motherboard UEFI/AGESA version, PCIe lane configuration, chipset drivers, and even CPU microcode can determine whether a specific drive hits the bug.
  • Community lists are investigatory tools, not blacklists. Until vendors publish validated, SKU‑level guidance, these lists should be used for triage only, not as definitive recall inventories.

Vendor and Microsoft Responses

Phison broke its silence in late August, releasing a statement: “Phison is aware of the industry‑wide effects that have been reported following the installation of Windows 11 update KB5063878. We are working closely with our partners and Microsoft to identify any potentially affected controllers and to provide partner advisories or firmware remediation as needed.” The company stressed that firmware fixes, when ready, will be distributed through the SSD brands that integrate Phison silicon—not via a standalone Phison consumer utility.

Phison also publicly disowned a forged internal advisory that had spread through enthusiast channels, labeling it falsified and indicating it would pursue legal remedies. The fake memo, which claimed permanent data loss across entire controller families, threw panic fuel on the fire. “Treat any internal advisory not posted on an official vendor channel as suspect until confirmed,” Phison warned.

Microsoft said it is “aware of these reports” and is investigating with storage partners. At the time of initial reporting, Microsoft’s internal telemetry had not shown a broad spike in disk failures, but the company invited affected customers to file Feedback Hub reports and open support cases so it could gather reproduction logs. Microsoft retains the option to issue a host‑side mitigation—such as a Known Issue Rollback (KIR) or a targeted kernel fix—if forensic analysis shows the update altered NVMe or HMB semantics.

Several branded SSD vendors are also collecting telemetry from their customer bases. Historically, when controller firmware is caught off guard by a host change, permanent fixes arrive as SKU‑specific firmware updates pushed through vendor utilities like Corsair iCUE, WD Dashboard, or SanDisk SSD Dashboard.

The Misinformation Problem: Forged Advisories and Why Accuracy Matters

The forged Phison memo claimed exhaustive internal testing had demonstrated “permanent data loss on all E13T‑based drives.” Phison’s swift denouncement highlights how quickly unauthenticated documents can cause real harm: panicked users initiate mass RMAs, engineering teams are sidetracked by legal and PR triage, and genuine forensic work gets delayed.

Other unverifiable claims circulating on social media—sweeping assertions that “all Phison controllers are bricked,” or exact failure counts without supporting logs—should be treated with extreme skepticism until validated by vendor telemetry or independent labs that publish full test logs.

Practical Guidance: What to Do Right Now

The immediate, defensible posture for both home users and IT administrators is conservative: protect data first, stage updates carefully, and avoid risky workloads until official remediation arrives.

  • Back up critical data now to an independent physical drive or cloud service. Backups are the only reliable defense against in‑flight write corruption.
  • If KB5063878 / KB5062660 has not yet been installed, stage it in a test ring and delay broad deployment until your SSD vendor and Microsoft give clearance for your specific hardware.
  • If you have already installed the update and have not seen problems, avoid sustained large sequential writes on potentially at‑risk drives. Split large file transfers into smaller chunks where feasible.
  • Check your SSD vendor’s management utility for firmware updates and advisories. Do not apply random firmware from forums; only use official tools after backing up your data.
  • For IT administrators and fleet managers: inventory SSD models, controller families, and firmware versions across your estate. Run representative sustained write tests (50 GB+ continuous) on sample hardware before approving wide deployment. Use WSUS, MECM, or Intune controls to pause or rollback the KB on at‑risk groups if necessary.

How Resolution Is Likely to Be Delivered

Three realistic, non‑exclusive remediation paths are typical in such coordination incidents:

  1. Controller firmware patches published by SSD brands – the most likely permanent fix where firmware logic needs adjustment. Expect SKU‑specific firmware IDs and change logs distributed through vendor tools.
  2. A Microsoft host‑side mitigation – a Known Issue Rollback, targeted patch, or driver update – if forensic work reveals the Windows update changed NVMe/HMB allocation semantics in a way that violates controller expectations.
  3. A hybrid approach where Microsoft issues a temporary mitigation or guidance while vendors validate and ship firmware fixes for affected controllers. This minimizes short‑term exposure and ensures long‑term robustness.

Independent reproducibility tests that demonstrate the failure no longer occurs for fixed combinations will be the final confirmation users and IT pros want to see. Until then, vendor firmware advisories and Microsoft release‑health entries remain the authoritative signals that the incident is resolved.

Technical Deep Dive: What Engineers Are Looking For

A definitive root cause requires correlated telemetry from both the host and controller stacks. Forensic teams inside Microsoft, Phison, and SSD vendors are likely examining:

  • NVMe command traces captured during reproduction runs.
  • SMART and vendor‑specific telemetry snapshots taken before, during, and after failure.
  • Host memory allocation (HMB) behavior and kernel traces showing when HMB is allocated, resized, or released.
  • PCIe error logs, bus enumeration events, and Windows Event Viewer entries around the time of failure.
  • Firmware revision, factory flash ID, and mapped NAND geometry to identify code paths that interact with mapping tables and garbage collection/wear‑leveling algorithms.

Engineers will test multiple permutations—firmware revisions, drive capacities, platform BIOS versions, CPU microcode, and storage drivers—to narrow the minimal reproducer and validate a fix without introducing regressions.

What to Watch Next: Timeline and Signals

Users and admins should monitor the following signals for resolution:

  • Official firmware advisories from major SSD brands that explicitly reference KB5063878 and contain SKU‑level firmware IDs and change logs.
  • Microsoft Release Health updates, KB addendums, or Known Issue Rollback notices that list storage regressions or offer mitigations.
  • Independent lab verifications and large‑sample reproductions showing that known fail combinations no longer trigger the bug.
  • Legal filings or public confirmations related to the forged Phison advisory, which would validate the company’s authenticity claims.

Strengths, Limitations, and Risk Assessment

The public evidence base carries significant weight:

  • Independent reproducibility by multiple outlets and community labs under identical workloads strengthens signal confidence.
  • Vendor acknowledgement from Phison elevates the issue from forum chatter to an official industry investigation.
  • Technical plausibility aligns with well‑understood failure modes when host/driver changes interact poorly with firmware, especially in HMB‑dependent designs.

However, important unknowns remain:

  • No single definitive public root cause has been released. Attribution remains a well‑supported hypothesis, not proven fact.
  • Community model lists are provisional; firmware revision, drive capacity, and platform variables dramatically alter susceptibility.
  • Potential confounders such as motherboard firmware, driver versions, and thermal behavior can change reproducibility, making blanket statements about entire controller families premature.

Overall risk to the average user is moderate, but the potential impact—data corruption or an inaccessible drive—is high. That combination justifies the conservative operational stance urged by experts.

Conclusion

The August 2025 Windows 11 cumulative update KB5063878 has triggered a reproducible storage regression that can cause certain NVMe SSDs to vanish during sustained large writes. Phison is actively investigating, coordinating with Microsoft and partners. The most likely fix path involves vendor firmware updates and possibly a Microsoft host mitigation. Until then, the safe play is clear: back up your data, avoid heavy write workloads on patched systems, and wait for official firmware updates from your SSD maker. Ignore forged internal memos and sensationalist social claims; the only trustworthy signals will come from vendor advisories and Microsoft’s release health dashboard.

Source: TechPowerUp forum thread "Phison Posts Latest Update on SSD Controller Stability" https://www.techpowerup.com/forums/threads/phison-posts-latest-update-on-ssd-controller-stability.340376