Windows 11 KB5063878 Storage Regression: Phison Investigates & Falsified Doc Denied

Phison has confirmed it is investigating a widespread storage regression tied to Windows 11’s August cumulative update (KB5063878) while simultaneously denouncing and legally challenging a circulated document that falsely claims to be an internal Phison report linking the problem exclusively to its SSD controllers.

Background / Overview​

Microsoft shipped the Windows 11 cumulative update identified as KB5063878 (OS Build 26100.4946) on August 12, 2025. Within days, community test benches and enthusiast channels began reproducing a clear failure fingerprint: under sustained, large sequential writes (commonly reported near the ~50 GB mark, especially when the target SSD was ~50–60% full), some NVMe drives stop responding, disappear from Windows (File Explorer, Device Manager, Disk Management), and in a subset of cases return as corrupted or inaccessible after a reboot. (tomshardware.com, notebookcheck.net)
That reproducible symptom set — sudden device disappearance during heavy writes, unreadable SMART/NVMe telemetry, and occasional partition corruption — points toward a controller- or firmware-level hang exposed by host-side behavior rather than a simple filesystem fault. Multiple independent outlets and hands-on reproductions confirm this fingerprint.
At the same time, a document claiming to be an internal Phison advisory began circulating on partner and enthusiast channels. Phison has unequivocally stated that the document is falsified, is not from the company, and that it is taking appropriate legal steps. The falsified material named specific controllers, used alarmist language about “permanent data loss,” and suggested the issue was unique to Phison — an assertion Phison disputes.

---

Timeline: how events unfolded​

Key milestones​

• August 12, 2025 — Microsoft publishes the August cumulative for Windows 11 (KB5063878). The public KB initially lists security and quality fixes and does not call out storage-device regressions.
• Within 48–72 hours — hobbyist testers and multiple tech outlets reproduce a repeatable failure profile during large sequential writes; community posts (including detailed tests shared by a Japanese enthusiast) become the primary early signal. (notebookcheck.net, guru3d.com)
• Mid‑ to late‑August 2025 — Phison issues a public acknowledgement that it is aware of “industry‑wide effects” linked to KB5063878 and the related KB5062660, says it’s investigating, and is coordinating with partners. Around the same time Phison declares a circulated document to be falsified and announces legal action.
• Ongoing — Microsoft, Phison, and SSD vendors continue to collect telemetry and coordinate forensic testing; firmware advisories and targeted mitigations are being prepared or tested. (bleepingcomputer.com, wccftech.com)

What the community did​

Independent labs and enthusiasts ran systematic write-stress tests on multiple drives and produced relatively consistent results: heavy sequential writes approaching ~50 GB on moderately full drives were the most repeatable trigger. Those community reproductions elevated the event from scattered reports to an industry investigation.

---

The falsified document: why it matters​

What the fake document did​

The circulated document — styled as a Phison internal advisory — listed specific controller families, presented anecdotal community reports as confirmed data, and used alarmist language about permanent data loss and a lack of remediation other than waiting for Microsoft. If believed by channel partners, system integrators, or customers, it could have caused widespread reputational and commercial harm to Phison and its customers.

Phison’s response​

Phison formally disowned the document, saying it was neither an official nor unofficial communication and that it is pursuing legal remedies. The company reiterated that while its controllers may have been among devices affected, the evidence pointed to an industry-wide regression with devices from multiple vendors implicated, and that remediation would require coordinated analysis and firmware/OS fixes.

Risks created by falsified claims​

• Misdirected blame: False documents can push partners and users to assume single-vendor fault before telemetry or forensic results support such claims, skewing triage and remediation efforts.
• Unnecessary panic: Alarmist language can increase RMA volumes, overload support channels, and trigger premature recalls.
• Legal and business exposure: Falsified material can prompt contractual disputes, retail delisting, or investor reaction based on incorrect information.
• Forensic confusion: If vendors respond to unauthenticated internal documents, forensic data may be misinterpreted or contaminated.

Phison’s legal posture is an important signal: beyond the technical resolution, accurate and authenticated communications matter in a cross‑industry incident where telemetry and coordinated forensic logs are the truth source.

---

Technical anatomy: why a Windows update can expose SSD fragility​

NVMe SSDs are embedded, co‑engineered systems​

Modern NVMe SSDs combine controller firmware, optional on‑board DRAM, NAND channel management, and host interactions (OS NVMe driver, DMA, and caching). A small change in how the host OS handles command ordering, buffer allocation, or memory lending can expose latent controller firmware edge cases. Community analysis and vendor statements point to two plausible mechanisms.

1) Host Memory Buffer (HMB) and DRAM-less designs​

Many cost-optimized NVMe SSDs omit dedicated DRAM and instead use Host Memory Buffer (HMB) to map logical-to-physical addresses. If Windows’ update changes timing, allocation, or lifetime semantics for HMB, that can expose race conditions or resource assumptions in controller firmware, leading to controller lockups under sustained metadata updates — precisely the workload pattern that reproductions highlight.

2) Sustained sequential-write stress and controller state​

Long, continuous writes stress mapping-table updates, SLC caching behavior, garbage collection, and metadata writes. A change in how the host issues flushes, orders commands, or manages DMA buffers can create an unusual command cadence the controller firmware wasn’t engineered to handle, causing the controller to become unresponsive until a power cycle or firmware reset. The observed unreadable SMART telemetry during incidents supports a controller-level hang hypothesis.

Why attribution is hard​

• The same workload produced differing outcomes across drives with the same controller family, indicating firmware revision, drive fill level, motherboard UEFI, NVMe driver versions, and platform interactions all matter.
• Non‑Phison drives were implicated in isolated reproductions, suggesting a host-to-controller interaction rather than a single-vendor firmware bug.

---

Who’s affected: vendors, models, and error profiles​

What early lists show​

Community-sourced lists repeatedly named drives that use certain Phison controllers (examples: PS5012‑E12 family and later E21T/E31T variants) — brands include Corsair, SanDisk, Kioxia, and several third-party SSD SKUs — but lists vary by thread and tester. Importantly, not every drive with a listed controller failed, and several non-Phison models also showed problems in isolated tests. Treat model lists as investigative leads, not definitive blacklists.

Symptom levels observed (practical triage)​

• NG Lv.0 — No issue observed under test; drive remains stable.
• NG Lv.1 — Drive disappears mid-write but recovers after reboot; some written files may be truncated.
• NG Lv.2 — Drive remains inaccessible after reboot; partition may be RAW or data corrupted; vendor intervention or RMA required. Community reproductions reported mixed distribution across these levels.

Real-world triggers​

• Large game downloads/updates (examples widely cited include Cyberpunk 2077 and major Steam updates).
• Archive extraction of large multi-gigabyte packages.
• Disk cloning or mass media copy operations.
  In lab tests, splitting transfers into smaller chunks often avoids the failure, which reinforces the sustained-write trigger theory.

---

Vendor and Microsoft responses​

Phison​

Phison acknowledged that it was “recently made aware of the industry‑wide effects” associated with KB5063878 and KB5062660, that certain controllers were under review, and that it is working with partners to provide advisories and remediation where applicable. The company publicly disowned the falsified document and says it is pursuing legal remedies.
Caveat: press coverage frequently reports Phison’s intent to take legal action; independent confirmation of filed suits, named defendants, or court documents was not always available at publishing time. Treat “legal action” as a vendor‑stated step pending public filings or court notices.

Microsoft​

Microsoft indicated it was aware of reports and investigating with partners. Historically, Microsoft addresses similar regressions using Known Issue Rollback (KIR) or targeted hotfixes if host behavior is implicated. Microsoft’s public KB initially listed no storage issues for KB5063878; that can change as telemetry and partner forensic data are reconciled.

SSD vendors and firmware​

Drive manufacturers are the typical distribution channel for firmware remediation. Phison provides controller firmware to partners, who test updates against their specific drive SKUs and customer utilities before mass deployment. Expect coordinated firmware updates to be delivered via vendor dashboards, with staged rollouts and SKU-specific release notes.

---

Practical guidance — immediate steps for users and IT teams​

The situation is evolving, but practical, conservative triage reduces exposure to data loss.

• Back up now. Use the 3‑2‑1 principle: three copies, on two different media, one offsite. Backups are the only reliable defense against low-level metadata corruption.
• Avoid heavy, continuous writes on recently updated systems. Delay large game installs, archive extractions, cloning, or mass media transfers until vendors confirm fixes.
• If you must transfer large data, split the workload into smaller batches (well under ~50 GB) and monitor the drive for signs of instability.
• Inventory drives: identify controllers and firmware versions using vendor utilities or tools like CrystalDiskInfo, and check vendor advisory pages before flashing firmware.
• For administrators: stage KB5063878 in representative fleets that include the range of storage hardware you deploy; hold updates for production until vendors publish validated mitigations.
• If a drive disappears during a write:
• Stop writing immediately.
• Note OS logs and event viewer NVMe/storage errors.
• Do not attempt unsafe firmware flashes without vendor guidance.
• Contact the SSD vendor’s support with logs and exact firmware/drive details.

---

Forensic and investigative needs: what will resolve root cause​

To attribute root cause definitively, coordinated telemetry is required:

• Controller-side logs and dumps (secure trace logs from Phison firmware).
• Host-side traces (Event Viewer, NVMe driver traces, DMA timing, and HMB allocations).
• Cross-correlation across affected and unaffected drives with identical firmware and platform to isolate variables.
• Controlled lab reproductions across UEFI/BIOS, driver versions, power-management states, and storage fill levels.

Only joint, instrumented analysis from Microsoft, controller vendors, and drive integrators can produce an authoritative remediation roadmap — either an OS-side fix, controller firmware patch, or a combination. Partial or anecdotal analysis risks misattribution.

---

Broader implications and long‑term lessons​

For users and IT purchasing​

This incident highlights the fragility of co‑engineered subsystems. Buyers and administrators should:

• Demand validated compatibility matrices and representative test rings from vendors.
• Use staged rollouts for OS updates, particularly on fleets with varied storage hardware.
• Favor drives with robust vendor update pathways and strong telemetry for enterprise use cases.

For vendors and platform maintainers​

• Better pre-release testing should include heavy, long-duration sequential workloads across a broader matrix (DRAM-less designs, HMB behavior, firmware versions).
• Transparent, authenticated communications are vital. The falsified document incident shows how misinformation complicates incident response and undermines trust.

For the industry​

An OS change exposing firmware edge cases isn’t unprecedented, but it underscores a recurring governance gap: who certifies and tests major OS updates across the hundreds of SSD firmware variants in the market? The practical solution path involves improved vendor cooperation, shared testbeds, and perhaps a standard for storage‑stack regression testing pre-release.

---

Critical assessment: strengths, weaknesses, and unresolved questions​

Strengths in the current response​

• Rapid community reproducibility accelerated vendor attention and produced test vectors useful to vendors and Microsoft.
• Phison’s public acknowledgement and legal rejection of the falsified document helps prevent misattribution and clarifies partner expectations.

Weaknesses and risks​

• Early public communications lacked granular telemetry or definitive attribution, leaving room for rumor and harmful speculation. The falsified document exploited that vacuum.
• The reliance on community testing — valuable but not comprehensive — means the full distribution and scale of the fault remain uncertain until vendor telemetry is publicly or cooperatively disclosed.

Unverified claims and cautionary flags​

• Public reporting that mentions specific legal filings against named parties should be treated cautiously until court records or formal notices are available; vendor statements so far indicate intent to pursue legal processes rather than providing documented filings in court.
• Any single-vendor attribution (i.e., only Phison is at fault) is not supported by the totality of available evidence; multiple vendors and controllers appear in isolated reproductions, pointing to a host‑to‑controller interaction rather than a universal controller failure.

---

Conclusion​

The August 12 Windows 11 cumulative update (KB5063878) produced a reproducible storage regression under sustained heavy writes that can render some drives temporarily or permanently inaccessible. Community labs and vendors concur on the failure fingerprint, and Phison has acknowledged it is investigating while disowning a circulated falsified document and pursuing legal remedies. The incident is a technical cautionary tale: modern storage depends on delicate host/firmware choreography, and the interplay of an OS update with controller firmware can surface latent failures with real data‑loss consequences. The immediate practical advice is clear: back up, avoid heavy sequential writes on patched systems, inventory affected hardware, and await coordinated, vendor‑tested firmware or OS mitigations.

---

---

Source: TweakTown False documents point the finger at Phison after Windows 11 update causes SSDs to fail