A wave of reproducible reports and a parallel burst of misinformation have combined to create one of the more consequential Patch Tuesday headaches in recent memory: Microsoft’s August 12, 2025 cumulative for Windows 11 (KB5063878) has been linked to SSDs disappearing under sustained, heavy write workloads, and Phison — a major SSD controller designer — has publicly acknowledged industry‑wide effects while simultaneously denouncing a circulated falsified advisory and saying it is pursuing legal remedies.
Microsoft shipped the combined servicing stack and cumulative update identified as KB5063878 (OS Build 26100.4946) on August 12, 2025. The update was rolled out as part of Patch Tuesday and packaged fixes that also pulled in prior quality updates. Microsoft’s official KB initially lists no known storage regressions, even as independent testers began reporting a clear failure fingerprint within days of the rollout.
Independent reproductions — starting with an enthusiast test bench and amplified across specialist outlets and forums — converged on a scenario that is narrowly specific, but potentially serious: sustained sequential writes in the tens of gigabytes (commonly mentioned around the ~50 GB mark) against drives that are moderately to heavily filled (commonly reported near or above ~50–60% capacity) can cause some NVMe SSDs to stop responding and disappear from Windows. In many cases the device reappears after a reboot; in a smaller, troubling subset the drive remains inaccessible or returns with corrupted filesystem metadata.
Phison acknowledged it had “recently been made aware of the industry‑wide effects” associated with KB5063878 (and the related KB5062660) and said it was investigating controller families “that may have been affected” while coordinating with partners. At the same time, a document purporting to be an internal Phison advisory — titled, variously, “Phison SSD Controller Issues Summary” — began circulating in distribution lists and on enthusiast channels. Phison called that document falsified and said it would take appropriate legal action.
Key technical hypotheses under investigation:
Microsoft routinely uses a mix of telemetry analysis, Known Issue Rollback (KIR), and targeted mitigations when a platform change causes field-impacting behavior. In past cross‑stack incidents, Microsoft has issued KIR or micro‑patches to limit the blast radius while vendors prepare firmware updates. That remains a plausible path here if forensic data points to host behavior as a root contributor.
SSD vendors must test controller firmware against branded SKUs before releasing updates because factory configurations, BOM variations, and vendor utilities can affect a firmware’s safety. Expect vendor‑specific firmware patches to roll out through support dashboards and utilities (e.g., Corsair iCUE, SanDisk Dashboard). Phison’s statement underscores that firmware fixes, when required, will be delivered via partners rather than direct end‑user downloads from Phison.
Critical points about the falsified‑document episode:
Immediate actions (prioritized):
Strategic improvements the ecosystem should consider:
In the immediate term the defensible, non‑speculative posture is clear and simple: back up critical data, delay or stage the update for at‑risk systems, avoid sustained large writes on patched systems, and follow only vendor‑published firmware advisories. Misinformation — including forged advisories — compounds harm and must be treated with skepticism until validated by vendor statements or legal filings. The path out of this incident is the usual, sober mix of forensic telemetry, coordinated vendor engineering, and cautious operational discipline.
Source: GIGAZINE Fake documents purporting to be from storage manufacturer Phison are spreading about Windows 11 update issues that cause SSD problems, and Phison is taking legal action
Background
Microsoft shipped the combined servicing stack and cumulative update identified as KB5063878 (OS Build 26100.4946) on August 12, 2025. The update was rolled out as part of Patch Tuesday and packaged fixes that also pulled in prior quality updates. Microsoft’s official KB initially lists no known storage regressions, even as independent testers began reporting a clear failure fingerprint within days of the rollout. Independent reproductions — starting with an enthusiast test bench and amplified across specialist outlets and forums — converged on a scenario that is narrowly specific, but potentially serious: sustained sequential writes in the tens of gigabytes (commonly mentioned around the ~50 GB mark) against drives that are moderately to heavily filled (commonly reported near or above ~50–60% capacity) can cause some NVMe SSDs to stop responding and disappear from Windows. In many cases the device reappears after a reboot; in a smaller, troubling subset the drive remains inaccessible or returns with corrupted filesystem metadata.
Phison acknowledged it had “recently been made aware of the industry‑wide effects” associated with KB5063878 (and the related KB5062660) and said it was investigating controller families “that may have been affected” while coordinating with partners. At the same time, a document purporting to be an internal Phison advisory — titled, variously, “Phison SSD Controller Issues Summary” — began circulating in distribution lists and on enthusiast channels. Phison called that document falsified and said it would take appropriate legal action.
What the community testing shows
Reproducible fingerprint
Multiple independent test benches reproduced a consistent sequence:- Install KB5063878 (or the related preview KB5062660).
- Fill target SSD to a moderate level (community tests often cited ~50–60% used).
- Execute a sustained, large sequential write — examples include cloning a drive image, installing a large game, or copying tens of gigabytes in a single pass.
- At or near ~50 GB of continuous writes, the target drive may stop responding, disappear from File Explorer / Device Manager, and become unreachable by vendor utilities and SMART readers. Some drives return after reboot; others do not.
Heuristics — the “50 GB / 60%” rule
Community posts converged on practical heuristics — roughly 50 GB of continuous writes and ~50–60% drive fill — as commonly reproducing the problem in test rigs. Those numbers are useful operational heuristics for triage, not definitive thresholds. They reflect patterns observed in controlled benches rather than deterministic failure criteria for every device in the wild. Treat them as risk indicators to guide mitigation and testing, not as immutable facts.Technical anatomy — why an OS update can expose SSD fragility
NVMe SSDs are tightly coupled systems in which the operating system, NVMe driver, PCIe bus, storage controller firmware, and NAND behavior all interact. Small host-side changes — especially those that adjust memory allocation, command ordering, or timing — can surface latent controller firmware edge cases.Key technical hypotheses under investigation:
- Host Memory Buffer (HMB) timing/semantics: DRAM‑less drives use HMB to borrow system RAM for mapping tables. If the update changed how Windows allocates, initializes, or tears down HMB, it could expose race conditions or lifetime assumptions in firmware, causing a controller lockup during heavy mapping-table updates.
- Sustained sequential‑write pressure: Long, continuous writes stress SLC caches, garbage collection, and metadata updates. A change in how the host issues flushes or orders NVMe commands could create a command cadence that some firmware revisions were not designed to handle. Reported unreadable SMART telemetry after incidents supports a controller-level hang or lockup.
- Platform/BIOS/driver permutations: Reproducibility varies with firmware revision, motherboard UEFI, NVMe driver version, and drive fill state. The same model can behave differently on different motherboards or with different BIOS versions. This multiplicity of variables complicates straightforward attribution.
Vendor and platform responses
Microsoft
Microsoft’s official KB for KB5063878 confirms the update’s release on August 12, 2025. The KB initially listed “no known issues” with the update, but Microsoft has engaged partners and said it is investigating customer reports raised via Feedback Hub and vendor channels. Separately, Microsoft moved quickly to address a WSUS delivery error (0x80240069) that affected enterprise deployments of the August cumulative. That WSUS problem has been resolved by Microsoft.Microsoft routinely uses a mix of telemetry analysis, Known Issue Rollback (KIR), and targeted mitigations when a platform change causes field-impacting behavior. In past cross‑stack incidents, Microsoft has issued KIR or micro‑patches to limit the blast radius while vendors prepare firmware updates. That remains a plausible path here if forensic data points to host behavior as a root contributor.
Phison and SSD vendors
Phison publicly acknowledged it was investigating “industry‑wide effects” tied to KB5063878 and KB5062660 and said it had engaged industry stakeholders to review potentially affected controllers. The company emphasized partner coordination and promised to provide advisories and remediation through SSD vendors, which is the typical channel for controller firmware distribution.SSD vendors must test controller firmware against branded SKUs before releasing updates because factory configurations, BOM variations, and vendor utilities can affect a firmware’s safety. Expect vendor‑specific firmware patches to roll out through support dashboards and utilities (e.g., Corsair iCUE, SanDisk Dashboard). Phison’s statement underscores that firmware fixes, when required, will be delivered via partners rather than direct end‑user downloads from Phison.
Independent outlets and corroboration
Multiple reputable outlets — Tom’s Hardware, BleepingComputer, Windows Central, TechRadar, and others — independently reported the failure fingerprint and the ongoing vendor investigation. Their hands‑on reproductions and community‑collated data sets are the primary early evidentiary basis for the incident. The broad, independent reporting helps validate that this is an industry‑level signal rather than an isolated campaign of noise.The falsified document and Phison’s legal posture
A document widely circulated on partner lists and social channels purported to be an internal Phison advisory naming specific controller families and asserting a definitive conclusion: that Phison controllers had “specific and significant issues” and that users should expect permanent data loss. Phison disowned that document, calling it falsified and saying it was neither an official nor unofficial company communication. Phison stated it is taking “appropriate legal action” against those distributing the forged advisory.Critical points about the falsified‑document episode:
- Why it matters: A forged advisory that claims exclusive responsibility by a single vendor can cause premature and damaging market reactions — RMAs, mass returns, reputational loss, and misguided engineering responses. The document’s alarmist framing risked diverting partner triage resources and escalating panic.
- Legal claims vs. verifiable filings: Phison’s public statement asserts legal action; however, independent confirmation of specific court filings, cease‑and‑desist recipients, or named defendants was not publicly available at the time of reporting. Treat the company’s legal posture as a stated intent unless and until formal filings or court notices are published.
- Possible motives: While speculation has run from opportunistic competitor leaks to malicious disinformation actors, the provenance and motive behind the forged document remain unproven. Forensic tracing of the document’s origin would be required to substantiate claims about who authored or distributed it.
Practical guidance for users and IT teams
The balance of evidence supports a conservative, risk‑first approach while vendors and Microsoft conduct a coordinated investigation and release validated mitigations.Immediate actions (prioritized):
- Back up irreplaceable data now to independent media or cloud. Backups are the single most reliable defense against mid‑write corruption and potential permanent loss.
- If you have not yet installed KB5063878 and your systems perform large sequential writes or use DRAM‑less or Phison‑equipped SSDs, delay deployment until vendors or Microsoft publish guidance. Enterprise update rings should hold the patch for a pilot group and perform targeted validation.
- Avoid sustained large single‑shot writes (> ~50 GB) on systems that already installed the update; split large transfers into smaller chunks where feasible. This is a practical risk-minimizing step until firmware or host mitigations appear.
- Inventory SSD models and firmware across your fleet. Prioritize drives that are heavily used and those with DRAM‑less designs for testing. Check vendor dashboards for firmware advisories before attempting updates.
- If a drive disappears during a write: stop writing, do not initialize or reformat the volume, collect Event Viewer and vendor diagnostics, create a block-level forensic image if possible, and contact vendor support. Capturing logs and telemetry is critical for any potential RMA or forensic recovery.
- Some advanced community workarounds (e.g., registry tweaks to limit HMB) have been used historically but carry performance penalties and risk. These should only be considered by experienced administrators with full backups and rollback plans.
- Do not apply vendor firmware blindly. Only flash firmware that is explicitly validated for your drive part number and vendor SKU, and always ensure backups first. Firmware updates can introduce other regressions if not properly matched to SKU and BOM.
Industry implications and lessons
This incident is a practical reminder that modern storage reliability is a co‑engineered outcome. The OS, NVMe drivers, controller firmware, motherboard firmware, and NAND characteristics must be stress‑tested as a system.Strategic improvements the ecosystem should consider:
- Expanded pre‑release stress testing matrices that include sustained sequential writes, high fill factors, HMB allocation scenarios, and combinations of vendor firmwares and BIOS revisions.
- A standardized minimal telemetry set that allows Microsoft and SSD vendors to rapidly correlate failure signals without exposing customer data; this would accelerate root‑cause analysis and reduce time‑to‑remediation.
- Faster vendor advisories that publish confirmed affected firmware IDs rather than relying on noisy community lists, reducing rumor-driven panic and enabling organized mitigation.
- Clear incident communication channels between platform vendors, controller IC suppliers, and SSD integrators so that firmware patches can be validated and distributed with minimal delay.
Critical analysis — strengths, weaknesses, and risks
Strengths in the response so far:- Measured vendor posture: Phison’s public acknowledgement avoided premature attribution and emphasized partner coordination and telemetry-driven forensic work. That measured stance reduces the risk of hasty, wrong‑headed remediation steps.
- Rapid community reproducibility: The fact that multiple independent benches reproduced a consistent fingerprint is a diagnostic positive — it provides actionable test vectors for vendors and Microsoft.
- Communication gaps: Early public messaging did not enumerate affected firmware IDs or a verified model list. That vacuum allowed noisy community lists to circulate and created the opportunity for fake advisories to be persuasive.
- Misinformation and legal uncertainty: Phison’s claim of legal action is a serious step intended to deter bad actors, but independent verification of formal filings or outcomes is not yet public. Legal steps may deter circulation but will not fix technical root causes.
- Operational exposure window: Firmware updates must be SKU‑specific and validated. That process can take time and leaves fleets exposed in the interim, particularly enterprises that prioritize immediate rollouts. Microsoft mitigations (KIR, targeted fixes) may help but require correct attribution.
Conclusion
The August 12 cumulative for Windows 11 (KB5063878) has produced a narrow but credible set of failure fingerprints under heavy, sustained write workloads. Independent test benches and specialist outlets have reproduced a repeatable scenario — the disappearing drive during large writes — and Phison has acknowledged industry‑wide effects while simultaneously denouncing a falsified advisory that misattributes exclusive blame. The technical evidence points toward a host‑to‑controller interaction that will likely require coordinated telemetry analysis, vendor firmware fixes, and possibly platform mitigations.In the immediate term the defensible, non‑speculative posture is clear and simple: back up critical data, delay or stage the update for at‑risk systems, avoid sustained large writes on patched systems, and follow only vendor‑published firmware advisories. Misinformation — including forged advisories — compounds harm and must be treated with skepticism until validated by vendor statements or legal filings. The path out of this incident is the usual, sober mix of forensic telemetry, coordinated vendor engineering, and cautious operational discipline.
Source: GIGAZINE Fake documents purporting to be from storage manufacturer Phison are spreading about Windows 11 update issues that cause SSD problems, and Phison is taking legal action