Phison, the Taiwanese NAND controller giant, has publicly disavowed a forged internal advisory that fueled panic over Windows 11 updates allegedly “bricking” SSDs, even as independent community tests revealed that 12 out of 21 drives vanished under heavy write loads. The coordinated investigation now sweeping across the storage industry exposes a messy intersection of authentic engineering flaws, misinformation, and the fragile co-dependence of operating systems and firmware.
In mid-August 2025, Microsoft shipped Windows 11 cumulative update KB5063878 (OS Build 26100.4946) as part of its Patch Tuesday cycle. Within days, power users on social media and forums began reporting that NVMe SSDs were disappearing mid-transfer during large file operations—often after 50 GB of sustained writes on drives more than half full. In some cases, drives became permanently inaccessible. The reports triggered an engineering scramble that has since drawn in Microsoft, multiple SSD vendors, and controller maker Phison.
Phison’s three-pronged response
Phison’s response has been swift and multi-layered. First, the company denounced a forged internal advisory that named specific controller families as defective and spread through enthusiast and partner channels. Phison labeled it “bogus,” threatened legal action, and warned against acting on unauthenticated information. HotHardware covered the disavowal, noting that the fake memo not only sowed confusion but also diverted engineering resources from root-cause analysis.
Second, Phison acknowledged the issue publicly. In a statement to Tom’s Hardware, the company said: “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… At this time, the controllers that may have been affected are under review and we are working with partners.” This direct admission elevated the episode from forum noise to an industry-wide concern.
Third, the company relayed that extensive lab testing—some summaries mention 4,500 hours—has not produced a universal bricking failure. Wccftech’s coverage emphasized Phison’s inability to reproduce certain faults in controlled conditions, though those numerical claims remain unverified by primary technical logs. Phison’s posture is thus a careful balance: denying alarmist narratives while committing to a transparent investigation.
Community reproducibility: 12 of 21 drives fail
While vendor labs wrestle with replication, the enthusiast community built a compelling corpus of real-world evidence. Japanese tester Nekorusukii (@Necoru_cat) compiled a now-famous test matrix: 21 SSDs subjected to heavy sustained writes—copying a game library folder, creating compressed archives, then writing the expanded data. The results were alarming: 12 drives became inaccessible during the test, and one (a Western Digital SA510 2TB) never recovered, even after a reboot. Crucially, failures struck controllers from Phison, Silicon Motion, and in-house designs, shattering the early hypothesis that only DRAM-less Phison drives were vulnerable. Tom’s Hardware first reported these tests.
Other corroborating reports include a SanDisk Extreme Pro M.2 that vanished after a 50 GB game update, only to reappear after a reboot—until the user rolled back KB5062660, and the problem ceased. BleepingComputer noted Microsoft’s initial telemetry did not show a broad spike in disk failures, but the consistent symptom fingerprint across independent testers strongly suggests a real, workload-dependent regression. The community evidence cannot be dismissed as anecdotal; it forms the core of the engineering investigation.
Why a Windows update can cripple SSDs
To understand how an OS patch can trigger storage failures, it’s essential to appreciate the embedded complexity of modern NVMe SSDs. Two technical mechanisms are prime suspects:
- Host Memory Buffer (HMB) sensitivity: DRAM-less SSDs rely on HMB—a sliver of system RAM allocated by the OS for mapping tables and caching. A Windows update that tweaks memory allocation timing or patterns can violate assumptions baked into controller firmware, precipitating a race condition or lockup.
- Sustained write pressure and SLC cache exhaustion: When a drive is over 50% full, its pseudo-SLC cache shrinks, forcing more aggressive garbage collection and metadata updates during long sequential writes. A latent firmware bug in these high-stress paths might never surface under ordinary desktop use but would reliably strike during large file transfers—exactly the observed scenario.
Both explanations align with community findings: drives disappear not from idle read errors but specifically under heavy, sustained writes, and symptoms mirror a controller firmware crash rather than a simple file-system glitch. The pattern looks like a controller lockup driven by a specific host-side sequence, leaving SMART data unreadable and the drive invisible to the OS.
Misinformation: the forged advisory that lit the fire
Before Phison’s official engagement, a forged internal advisory leaked online, ostensibly naming vulnerable Phison controller models and warning of imminent mass bricking. The document, which Phison has called “bogus” and is pursuing legally, triggered premature RMAs and inflamed social media. It also created a signal-to-noise nightmare for engineers trying to isolate real failure patterns.
This incident underscores a growing problem in hardware crises: the speed at which fraudulent documentation can shape public perception and manufacturer liability. Accurate, timely vendor communication becomes doubly critical when forged narratives compete with legitimate investigation. Phison’s energy spent on legal containment could have otherwise gone to pure technical triage.
Who and what is actually at risk?
The available data points to a high-impact but low-prevalence bug. High impact: when a drive vanishes mid-write, data can be silently corrupted or lost entirely, and a subset of drives remain inaccessible until specialized recovery or OEM reflash. Low prevalence: it requires a specific set of conditions—Windows 11 installation with KB5063878 or KB5062660, sustained sequential writes exceeding roughly 50 GB, and a drive that is more than 50–60% full. Not every user will trigger it, but those who do risk catastrophic data loss.
Devices flagged in community lists share traits: they often use DRAM-less designs, rely on HMB, and span multiple controller families. While Phison-powered drives were over-represented in early reports, the Nekorusukii test demonstrates that no single vendor’s silicon is immune. Firmware revision, NAND configuration, and even motherboard BIOS/UEFI settings further modulate vulnerability. Treat crowd-sourced “affected model” lists as investigative leads, not definitive recall inventories.
Remediation pathways
Durable fixes will likely come from two directions:
- Firmware updates from SSD vendors: Controller makers must issue validated firmware revisions that correct the exposed logic. Distributing these patches through OEM utility suites (Corsair iCUE, WD Dashboard, Samsung Magician, etc.) will be critical.
- Microsoft mitigations: The company could ship a Known Issue Rollback (KIR) to temporarily reverse the triggering change, or place a safeguard hold in Windows Update to block the patch on vulnerable configurations until firmware is deployed. Both tactics have been used in past cross-stack regressions.
For users, the immediate imperative is data protection, not panic. Back up irreplaceable files to an external drive or cloud service. Avoid single-run transfers over 50 GB on updated systems until your drive model receives a firmware fix. Use vendor diagnostic tools to snapshot your SSD’s model, firmware version, and controller ID. For IT administrators, pilot the update in limited rings and run representative write-stress benchmarks before broad deployment.
Broader lessons for the Windows ecosystem
This episode exposes a structural fragility in the Windows servicing model. As OS updates become more frequent and hardware heterogeneity explodes, testing every combination of SSD firmware, controller, and workload becomes impractical. Two systemic improvements are overdue:
- Expand pre-release test matrices to include HMB-heavy DRAM-less SSDs under sustained write loads.
- Establish faster, structured telemetry-sharing protocols between Microsoft and firmware vendors so that field anomalies can be correlated with controller traces in hours, not days.
Without these investments, the industry will continue to stumble into rare but damaging edge cases that erode user trust.
Forward look
The immediate panic has subsided: Phison is not admitting to a universal bricking bug, and Microsoft has not confirmed a direct causal link. Yet the community evidence is too consistent to ignore. A formal post-mortem—with published test logs, root-cause analysis, and coordinated firmware/OS patches—would be the quickest path to restoring confidence. Until then, caution is the watchword.
The story of Windows 11’s vanishing SSDs is less about a single buggy update and more about the delicate dance between an ever-evolving OS and the multitude of intelligent devices it must support. For users, the moral is as old as computing itself: backup early, backup often, and never let a single point of failure exist without a safety net.