A forged internal memo claiming Windows 11’s August cumulative update was catastrophically destroying Phison-based SSDs was publicly disowned by Phison this week, even as the storage controller maker acknowledged investigating “industry-wide effects” linked to the update that have been independently reproduced across multiple NVMe drive brands. The real-world fallout: dozens of drives disappearing from Windows systems mid-transfer, some never recoverable, and a wave of community-driven forensic testing that has exposed a brittle interaction between Microsoft’s latest security patch and modern NVMe firmware.

Microsoft released KB5063878 (OS Build 26100.4946) on August 12, 2025, as part of its regular Patch Tuesday cadence. The update, described by the company as containing “security and quality fixes,” initially showed no signs of the storage regression that would soon dominate forums and social media. Within days, however, a reproducible failure pattern emerged: under sustained sequential writes—commonly around the 50 GB threshold on drives filled to roughly 50–60% capacity—certain NVMe SSDs would stop responding, vanish from File Explorer and Device Manager, and in severe cases, remain inaccessible or return with corrupted file system metadata after a reboot.

The community replication that triggered alarms

The pattern was first widely publicized by X user Nekorusukii, who noticed that his SSD disappeared during a large Cyberpunk 2077 update on a Windows 11 24H2 system with KB5063878 installed. Curious and technically adept, he assembled a test bench that reproduced the failure by copying Steam library folders, creating compressed archives, and then extracting them directly onto target drives. The results, collated and shared online, were striking: out of 21 SSDs tested, 12 became inaccessible during the write operation. All but one—a Western Digital SA510 2TB—recovered after a system reboot.

Those findings were quickly corroborated by independent tests from outlets like Tom’s Hardware, BleepingComputer, Windows Central, and niche Japanese tech sites. The consistent fingerprint across multiple independent benches—large sequential writes of ~50 GB on moderately filled drives—transformed the issue from anecdotal noise into a verifiable, cross-vendor phenomenon. Notably, while early reports disproportionately flagged drives using Phison controllers, the expanded test list included SSDs based on other silicon as well, hinting at a host-level trigger rather than a single-controller defect.

The forged advisory that blurred the facts

As community lists grew and alarm spread, a document surfaced in partner channels and enthusiast forums that purported to be an internal Phison advisory. It named specific controller families, used language about “permanent data loss,” and placed sole blame on the Windows update for uniquely killing Phison-based products. The “advisory” was quickly identified as a fabrication, but not before it had been widely shared, prompting some users to initiate unnecessary returns and flooding support pipelines with confusion.

Phison moved to publicly disown the document, issuing a statement that it was neither an official nor unofficial company communication and warning that it would pursue “appropriate legal action” against those distributing the forged material. At the same time, the company acknowledged the real regression. “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,” the statement read. “At this time, the controllers that may have been affected are under review and we are working with partners.” That careful wording underscored a dual reality: a genuine technical problem exists, but its scope and root cause are too complex for hasty attribution.

Technical hypotheses: host memory buffer and command timing

The reason the problem is not confined to one vendor points to a cross-stack interaction, likely involving how Windows handles NVMe commands and, in particular, Host Memory Buffer (HMB) allocation. Many modern consumer SSDs, especially DRAM-less models, rely on HMB to borrow a small slice of system RAM for mapping tables. This design is cost-effective but introduces a dependency on the OS for memory management timing and synchronization.

One leading hypothesis: KB5063878 altered HMB allocation, teardown, or timing semantics in ways that expose race conditions in certain firmware implementations. If a drive’s firmware assumes HMB memory will persist in a certain pattern, but Windows now reclaims it earlier or changes its caching behavior, the controller can encounter an unhandled state and hang. The observed symptom—loss of device enumeration and unreadable SMART telemetry during the hang—aligns with a controller-level lockup that requires a power cycle to clear.

A second, complementary theory involves sustained sequential write stress and how the OS paces NVMe commands. Large, continuous writes push SLC caches, mapping table updates, and garbage collection to their limits. If the Windows update adjusted the ordering or timing of flush commands, or altered DMA buffer management, it could hit unvalidated cadences in firmware that assume a narrower range of host behavior. The result may be a command timeout or a firmware watchdog triggering a shutdown, again manifesting as a disappearing drive.

Because these interaction points vary with exact firmware revision, motherboard chipset, UEFI version, and driver stack, two “identical” SSD models can behave differently across systems. This variability has made crowdsourced lists valuable but also noisy, reinforcing the need for vendor-validated telemetry to isolate the root cause definitively.

What the data really shows: cross-vendor impact

The 21-drive test conducted by Nekorusukii, while a single-system snapshot, provided a crucial signal. Drives from multiple brands—not just those using Phison controllers—dropped out during the test. The sole unrecoverable drive was a Western Digital model, further undercutting the narrative that only Phison silicon was at risk. Japanese outlet NichePCGamer aggregated reports from at least eight additional users, including one on a SanDisk Extreme Pro M.2 NVMe drive that repeatedly disappeared during large game updates until the user rolled back the Windows update.

Even so, these field reports have limitations. They lack the controlled telemetry that SSD makers and Microsoft can access at scale—controller logs, exact command traces, and host-side storage stack events. That’s why Phison and other vendors are engaging directly with Microsoft, and why the company’s statement emphasizes “working with partners” rather than issuing unilateral fixes. Microsoft, for its part, has not yet added a known issue acknowledgment to the KB5063878 page, but historically the company has used Known Issue Rollback (KIR) to disable problematic code changes while firmware fixes are prepared. That remains a plausible short-term remediation path.

The misinformation spiral and its consequences

The fake Phison advisory didn’t just muddy the waters—it introduced tangible operational risks. System builders and corporate IT teams, seeing what appeared to be an official alert, might have initiated blanket recalls or halted deployments for Phison-based systems alone, leaving other vulnerable configurations exposed. Returns and support tickets for unaffected drives waste resources and delay root-cause resolution. In this case, the forgery also primed some readers to mistrust genuine vendor communications, complicating the uptake of future legitimate advisories.

Phison’s mention of legal action, while a strong signal, is reactive and slow. The more urgent need is for clear, timely advisories that list affected firmware IDs, known-safe firmware versions, and validated workarounds. Until those appear, the vacuum will be filled by unofficial patchwork—some useful, some dangerous. For example, registry tweaks that forcibly disable HMB have been discussed in advanced circles, but these can severely degrade performance and carry their own stability risks if misapplied.

Practical defense: what users and IT administrators must do now

For anyone running a Windows 11 system with the August updates installed, the immediate priority is data protection. Large sequential writes are common—game installers, video exports, database backups—and the failure mode can corrupt file system metadata without warning.

  1. Back up irreplaceable data now. Use the 3-2-1 rule: three copies, on two different media, one offsite. Backups are the only reliable insurance against mid-write corruption that renders a drive inaccessible.
  2. If you have not yet installed KB5063878 (or its preview, KB5062660) and you regularly perform large writes, delay the update. Microsoft’s regular security improvements are important, but the risk of data loss outweighs the benefits until a fix is published.
  3. If the update is installed, avoid sustained single-shot writes larger than ~50 GB. Split large transfers into smaller batches. This is a temporary workaround that has prevented the hang in many user reports.
  4. Inventory your SSDs and firmware versions. Tools like CrystalDiskInfo can identify model numbers and firmware revisions. Pay special attention to DRAM-less or HMB-dependent drives, which appear at higher risk. Stage any update in a test ring that mirrors production hardware.
  5. If a drive disappears mid-write, stop writing immediately. Do not attempt to force write operations; instead, collect Event Viewer logs and vendor diagnostics, and create a block-level forensic image before attempting recovery. Contact the SSD vendor’s support with the logs—imaging ensures you have a pre-recovery snapshot for potential data reconstruction.

For enterprise IT, these steps should be integrated into standard change management: pilot the update on representative hardware, monitor for SMART errors and sudden device removals, and be prepared to roll back via KIR if Microsoft publishes one.

What the industry should learn from this

This incident is a textbook example of a cross-stack bug: an OS patch inadvertently pushes the envelope on firmware assumptions that were never stress-tested under combined conditions. It underscores two critical gaps in the modern storage ecosystem.

First, pre-release validation for Windows updates must be expanded to include sustained sequential write workloads with HMB-active DRAM-less SSDs across a range of firmware and chipset configurations. The fact that the failure fingerprint appeared within days of Patch Tuesday suggests that existing compatibility testing did not probe this interaction deeply enough.

Second, the incident reveals a communication void that a forged advisory exploited. When Microsoft and SSD vendors do not quickly publish authoritative, firmware-ID-specific advisories, unofficial lists become the de facto truth. A standardized, privacy-respecting telemetry exchange between OS platform owners and storage vendors would allow faster correlation without exposing user data, enabling Microsoft to deploy KIR mitigations and vendors to push firmware updates with confidence.

Phison’s public disownment of the fake advisory, while necessary, also highlights a reputational vulnerability: in a crisis, misinformation spreads faster than verified telemetry. To inoculate against future fabrications, vendors should invest in real-time status dashboards that cryptographically prove the authenticity of their security and compatibility advisories.

Looking forward: remediation and recovery

As of this writing, neither Microsoft nor affected SSD vendors have released a permanent fix. Microsoft is reportedly investigating via Feedback Hub reports and partner channels. The most likely short-term measure is a Known Issue Rollback that disables the specific codepath responsible for altered HMB or command ordering behavior, buying time for firmware revisions. KIR rollouts are typically silent and do not require a reboot, which would help disrupt the ongoing exposure.

For SSDs that have already become permanently inaccessible, the road to recovery is uncertain. The Western Digital SA510 case from the community test suggests that under rare circumstances, firmware corruption or metadata damage can brick a drive. Users with such a failure should prioritize cold-storage backups and engage their drive manufacturer for engineering-level recovery options.

The broader lesson is not new but bears repeating: production systems should not rush into major platform updates without a tested rollback plan. For Windows 11 users, that means deferring monthly quality updates by at least a week in enterprise environments and ensuring backup verification completes before allowing large data transformations.

As the investigation unfolds, the community’s rapid reproduction of the failure fingerprint has been invaluable—it provided the concrete, repeatable test case that moved vendors from observation to active engagement. Now, the onus is on Microsoft and the storage industry to close the loop quickly: isolate the offending host change, validate firmware patches that remove latent timing assumptions, and build communication channels that are faster and more resistant to forgery than a half-real community post. Until then, backup, delay, and test remain the only safe strategy.