Phison, one of the largest SSD controller designers, has publicly acknowledged a cluster of storage failures linked to Microsoft’s August 2025 Windows 11 cumulative updates and says it is investigating the reports with industry partners. The statement marks the first official recognition from a major silicon vendor that the August patches—tracked as KB5063878 and the related KB5062660—can trigger drives to disappear from the operating system under sustained write loads, and in a small but alarming number of cases, leave data corrupted or unrecoverable even after a reboot.

The admission elevates what began as a scattering of forum posts and X threads into a serious enterprise incident. Phison’s controllers power scores of consumer OEM and branded SSDs, from Corsair MP600-series drives to models from Kioxia, SanDisk, and ADATA, meaning a controller-level fragility has the potential to ripple across the storage ecosystem.

The August patches that lit the fuse

KB5063878 (OS Build 26100.4946) landed as part of Patch Tuesday with the usual payload of security and quality fixes. Within days, independent testers and hardware outlets began reproducing a remarkably consistent failure fingerprint. The update alters low-level NVMe and storage driver behaviour—likely in areas such as Host Memory Buffer (HBM) allocation, DMA timing, or command ordering—which, when combined with certain controller firmware revisions, causes the drive to silently drop off the bus under heavy sequential writes.

KB5062660, a preview of the same month’s non-security fixes, also appears in reproduction reports, suggesting the problematic change was baked into the month’s broader cumulative package early on. Neither Microsoft nor Phison have yet isolated the precise kernel or driver delta responsible, but the correlation between the August updates and the sudden wave of disappearing drives is too strong to dismiss as coincidence.

What the failures look like—a reproducible fingerprint

Community reproductions and specialist lab tests have sketched a detailed symptom profile that any user or admin can use as a diagnostic baseline:

  • Large sequential writes are the trigger. In almost every documented reproduction, the failure occurs during sustained, continuous write operations—game installs, mass file copies, archive extractions, or video exports—that exceed roughly 50 GB of transferred data. Splitting the same workload into smaller chunks often avoids the problem.
  • The drive vanishes from Windows. The target SSD (or, in a few reports, a HDD) disappears from File Explorer, Device Manager, and Disk Management. SMART and vendor telemetry become unreadable during the event, pointing to a controller-level hang rather than a simple file system error.
  • A reboot restores visibility—usually. In most cases, a power cycle or warm reboot brings the drive back. However, a subset of testers and affected users report that the drive remains inaccessible after reboot, with partitions written in the failure window corrupted or lost entirely.
  • Drive fill level matters. Many testers observed that drives already more than 50–60% full were more likely to fall over. This hints that the bug interacts with internal mapping-table maintenance, garbage collection, or the way the controller juggles its metadata when free space is scarce.

One of the most widely cited community reproductions came from X user Nekorusukii, who tested 21 drives by copying a large Steam library folder, compressing it, and then writing the expanded archive. Twelve of the 21 drives became inaccessible during the test. All but one—a Western Digital SA510 2 TB—recovered after a reboot. The outlier drive remained dead, driving home the real risk of permanent data loss.

Other independent reports include a SanDisk Extreme Pro M.2 NVMe SSD that repeatedly vanished after installing a 50 GB update for Honkai: Star Rail. The user deleted KB5062660 and the problem stopped, providing a clean time-correlated signal.

Which hardware is showing up—and why the list is messy

Community-sourced model lists have repeatedly named drives built around several Phison controller families—PS5012-E12 and the newer E21T/E31T lineage being the most discussed. Branded examples such as the Corsair MP600 and various SanDisk and Kioxia NVMe drives appear over and over. However, the picture is not a clean Phison-only recall. The same testing rigs also reproduced failures on non-Phison drives, including the aforementioned WD SA510, which uses a different controller.

This heterogeneity means the root cause sits at the intersection of the Windows kernel’s storage stack and a class of controller behaviour, not a single vendor’s bug. Phison’s over-representation in early results likely reflects the installed base—their controllers are extremely common in value and performance NVMe SKUs—rather than an exclusive defect. Until SSD brands publish validated inventories, community lists serve as investigative leads, not authoritative recall notices. Sysadmins should cross-reference any suspect model against their own firmware revision and deployment context before taking action.

Technical anatomy: why a Windows update can break SSDs

To understand how a security patch can make a drive disappear, you have to look at the tight choreography between the host OS, the NVMe driver, the controller’s embedded firmware, and the NAND itself.

HMB and DRAM-less designs

Many cost-optimised SSDs drop the on-board DRAM cache and instead rely on the NVMe Host Memory Buffer feature, which borrows a slice of system RAM for mapping tables and write buffering. If a Windows update changes how HMB is allocated or how the host releases those buffers under pressure, a controller that assumed a particular timing will suddenly find its metadata out of sync. The result is typically a controller hang or a firmware assertion failure. Windows 11 24H2 already had early HMB-related hiccups with some drives, making this a plausible recurring theme.

Firmware race conditions under sustained load

Sustained sequential writes stress every part of the controller’s state machine—mapping-table updates, garbage collection, SLC cache depletion, and internal metadata commits all happen at once. A subtle shift in the ordering of NVMe commands, the staging of buffered I/O, or the timing of completion interrupts can violate assumptions deep inside mature but untested firmware code paths. The controller may stop responding to admin commands, corrupt its internal state, and effectively vanish from the PCIe bus. The fact that SMART telemetry becomes unreadable during the failure strongly supports a controller hang or firmware lock-up, not a simple driver glitch.

Neither mechanism excludes the other. The most likely real-world explanation is a hostile interaction between the updated host driver stack and a latent flaw in certain firmware revisions. This is precisely why Phison and Microsoft now have to collaborate on telemetry-driven diagnostics.

What Phison actually said—and what it means for remediation

Phison’s statement, provided to Tom’s Hardware and other outlets, was measured:

“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. … At this time, the controllers that may have been affected are under review and we are working with partners.”

The wording carries two important signals. First, Phison confirmed that the problem is real and that it has already mobilised with partners—meaning SSD vendors are not just reading forum threads, they are actively involved. Second, the company explicitly deferred any fixed list of affected controllers and any customer-facing firmware release, promising updates “to partners” rather than directly to end users. This is standard for a controller supplier: each branded SSD—even those using identical silicon—may have unique firmware branch, board layout, and flash NAND configuration. Any patch must be integrated, validated, and distributed by the OEM, not Phison.

Firmware fix, OS mitigation, or both?

The path to resolution splits into three realistic outcomes:

  • Controller firmware fix. If the root cause is that firmware fails to handle a valid but new NVMe command cadence introduced by the update, then SSD vendors will need to publish per-model firmware updates. Phison’s partner-centric statement strongly suggests this scenario is on the table.
  • Microsoft host mitigation. If telemetry shows the update altered timing or buffering in a way that breaks established expectations, Microsoft can issue a Known Issue Rollback, a targeted hotfix, or a compatibility hold to restore previous behaviour. Microsoft has used KIR before for storage-related regressions, so the mechanism exists.
  • Hybrid approach. The most likely real-world fix combines an initial host-side mitigation to stop the bleeding while vendors test and release firmware patches for long-term robustness.

Until official advisories drop, IT teams should plan for a path that involves both verifying firmware revisions across their fleet and monitoring Microsoft’s release-health dashboard.

Immediate steps for users and enterprise IT

Because the failure can eat data—and in rare cases brick a drive—the playbook is conservative and urgent.

  1. Back up everything now. This is not a drill. Write your critical data to an external disk, a NAS, or cloud storage before attempting any large file transfers on a patched system. If a drive dies mid-write, the backup is your only lifeline.
  2. Delay or stage the update. If you haven’t yet installed KB5063878/KB5062660 and you work with large files or suspect your hardware is at risk, pause that update. Enterprises should ring-fence the patches with WSUS/MECM/SCCM and run validation on representative hardware before broad rollout.
  3. Avoid heavy sequential writes on patched systems. On any machine that already has the August update, do not initiate sustained write operations larger than ~50 GB. If you must move large data, split it into smaller chunks—tedious but safe.
  4. Check your SSD vendor’s toolkit. Open Corsair iCUE, SanDisk Dashboard, Kioxia SSD Utility, Crucial Storage Executive, or whatever your drive brand provides. Look for firmware advisories. Only apply firmware updates after making a full backup and reading the vendor’s release notes carefully.
  5. For enterprise admins:
    - Inventory drive models, controller families, and firmware revisions across all endpoints.
    - Add a sustained sequential write test (copy a large compressed archive, expand it, copy the expanded folder) to your prerelease validation suite.
    - Flag any drives already showing >60% capacity utilisation for extra monitoring.

If a drive disappears mid-write:
- Stop all writes immediately; do not power-cycle the drive repeatedly in an attempt to recover it—every spin-up can make things worse.
- If possible, create a forensic read-only image using ddrescue or a vendor tool before attempting recovery.
- Capture Event Viewer logs (System log, filter for disk and NTFS events) and open a ticket with the SSD vendor. Escalate for RMA if data is already lost.

Strengths of the evidence—and the gaps

The story is credible, but every IT decision must account for what we don’t yet know.

What’s solid:
- Independent reproducibility across multiple testers, hardware configurations, and geographic regions.
- A clear temporal link to the August cumulative updates; one user even demonstrated symptom resolution by removing KB5062660.
- Phison’s formal acknowledgement, which implicitly validates the community findings and signals that behind-the-scenes forensics are matching user reports.
- The failure signature (drive disappears mid-write, unreadable SMART) is technically consistent with a controller hang, not a generic Windows bug.

What’s still unknown:
- No public root-cause analysis. Neither Microsoft nor a storage vendor has published a forensic breakdown tying a specific kernel change to a specific firmware fault.
- Community model lists are provisional. Firmware version, platform firmware (BIOS/UEFI version), and even the specific NAND chips in a given manufacturing batch all influence exposure. A drive that fails in one test rig may survive in another.
- The scope is unclear. The evidence suggests the probability of a random user hitting this bug is low to moderate, but the impact when it does hit is high—making risk assessment difficult for large fleets.

Broad statements that “all Phison drives are bricked” are incorrect and unhelpful. The situation is nuanced, and telemetry from both vendors and Microsoft will ultimately determine which firmware/host combinations need attention.

A systemic lesson for the Windows storage ecosystem

This incident is a textbook illustration of the fragility that emerges when a PC platform is not a single product but a co-engineered mix of silicon, firmware, drivers, and OS. Modern NVMe SSDs—especially DRAM-less designs that borrow host RAM—depend on implicit timing and allocation contracts between the OS kernel and the controller. A cumulative update that tweaks those contracts, even unintentionally, can exercise untested code paths and trigger data-loss failures.

The technical remedy is clear: cross-vendor telemetry, firmware updates, and, where necessary, OS-side mitigations. The bigger challenge is organisational. Phison’s acknowledgement opens the door to coordinated remediation, but it will take weeks of validation before model-specific firmware updates are ready. In the meantime, the burden of protecting data falls on users and IT departments, and they need clear, conservative guidance.

What to watch for next

  • Vendor firmware advisories. SSD brands like Corsair, Kioxia, SanDisk, and ADATA will likely publish firmware updates for affected SKUs once they have validated Phison’s patches. Bookmark their support pages.
  • Microsoft release-health entry. A Known Issue entry for KB5063878/KB5062660, possibly with a KIR or compatibility block for enterprise channels, is a strong possibility if OS-side mitigation turns out to be necessary.
  • Third-party lab reports. Expect one or more large test outfits to publish consolidated telemetry correlating failure rates with specific firmware revisions and host configurations. That data will be gold for admins needing to craft precise compatibility holds.
  • Root-cause whitepapers. If the root cause is a subtle timing race, a technical deep-dive from Phison or Microsoft could help the industry harden NVMe implementations more broadly.

Final assessment

The August 2025 Windows 11 cumulative updates introduced a storage regression that, under sustained large sequential writes, can cause some SSDs to vanish from the operating system and, in rare cases, suffer permanent data loss. Phison has publicly confirmed it is investigating and has engaged its partners—a significant step that transforms forum noise into an industry-recognised incident. The exact list of affected controllers and the fix path (firmware, host mitigation, or both) remain works in progress.

For now, the defensible posture is simple and universal: back up, avoid heavy sequential writes on patched machines, stage the update in test rings, and monitor your SSD vendor’s support channel. Phison’s announcement is the beginning of the remediation effort, not the end. Administrators and cautious consumers should treat this as a high-impact, low-probability threat—and act accordingly.