A cumulative update for Windows 11 has triggered a worrying storage regression that causes certain SSDs to disappear during heavy write operations, prompting investigations from SSD controller makers Phison and Silicon Motion, with the latter claiming its controllers are unaffected. The update, identified as KB5063878 (build 26100.4946) and shipped as part of the August cumulative rollout, introduces a change in host behavior that can drive NVMe drives—and some SATA models—into an unresponsive state under sustained sequential writes. Multiple independent test labs and specialist outlets have reproduced the failure, elevating the issue beyond isolated anecdotes to a verified industry concern.

When a system with KB5063878 performs a continuous write of roughly 50 GB or more, the target SSD may stop responding to NVMe admin commands. The drive vanishes from Device Manager and Disk Management, vendor utilities lose contact, and SMART telemetry becomes unreadable. In some cases, a reboot restores the drive; in others, it remains inaccessible and may require vendor intervention or a reformat to recover. Files being written at the moment of failure can be truncated or corrupted, posing a direct risk of data loss.

The issue was first widely reported by a Japanese outlet, NichePCGamer, after X user @Necoru_cat documented the failure on several consumer SSDs. Early testing pointed to an overrepresentation of Phison-based controllers and DRAM-less designs, though other controller families have also surfaced in isolated reports. Phison publicly acknowledged it was investigating “industry-wide effects” and coordinating with partners. Microsoft confirmed it is “aware of these reports” and asked affected customers to submit telemetry via the Feedback Hub.

Amid the broader investigation, a forum post relayed as coming from Silicon Motion suggested that none of its controllers had exhibited the problem in internal testing or customer reports. While this is a positive signal for owners of drives built around SMI controllers, the claim currently lacks the weight of a formal vendor advisory or a published firmware validation list. The community is treating it as encouraging but provisional.

How the failure unfolds

The consistency of the reproduction fingerprint across dozens of drive models and test benches points to a host-side trigger rather than a random firmware defect. During a sustained write—often exceeding 50 GB—the SSD’s controller hangs, and any subsequent attempts by the OS to communicate fail. The drive disappears at the PCIe/NVMe level, and Windows logs may show I/O errors or device removal events. If the drive requires a reformat, any data stored on it before the failure is at risk.

Not all drives recover on reboot. Testers have noted that even after power cycling, some units remain invisible until the firmware is reflashed or the drive is reinitialized. This suggests that the controller enters a state from which it cannot exit without external intervention, possibly due to corruption in its internal mapping tables or a stall in the flash translation layer.

Probable technical mechanisms

Two interacting hypotheses dominate the community analysis:

  • Controller firmware hang due to host timing changes: A change in how the OS allocates or synchronizes buffers, interacts with the Host Memory Buffer (HMB), or orders direct memory access (DMA) can push some controller state machines into an unrecoverable state under sustained stress. The controller ceases to respond at the PCIe/NVMe level, and the OS treats it as removed.
  • HMB / DRAM‑less sensitivity: DRAM-less controllers that rely on the HMB are particularly sensitive to changes in host allocation semantics. If the update alters timing or mapping behavior, the controller’s expectation of stable HMB semantics can be violated, exposing race conditions that lead to stalls.

These mechanisms are consistent with the observation that DRAM-less SSDs and those using Phison’s HMB-reliant architectures appear overrepresented in early reproductions. However, definitive root cause requires cross-stack analysis from Microsoft and controller vendors across multiple firmware revisions.

What vendors have said

Phison: On recognizing the pattern, Phison issued a statement acknowledging it was investigating potential industry-wide effects linked to the August cumulative update (and a related preview patch) and was working with partners to determine affected controllers and remediate where necessary. This acknowledgment elevated the incident from isolated reports to an organized vendor triage.

Microsoft: In response to press inquiries, Microsoft said it was “aware of these reports” and asked affected customers to provide telemetry via the Feedback Hub while it works with storage partners to reproduce and diagnose the issue. At the time the reproductions surfaced, the KB page for KB5063878 did not immediately list a storage-related Known Issue.

Silicon Motion: According to a TechPowerUp forum thread and subsequent collations by specialist outlets, a response attributed to Silicon Motion indicated that none of the company’s controllers had experienced the issue in its testing or in customer reports to date. For Silicon Motion‑based SSD owners, this is a reassuring datapoint. However, the reply was delivered through a community forum, not an official support bulletin, and does not include the SKU‑level firmware details that enterprises and cautious users require. Without a published advisory, the claim remains provisional.

What drives are affected?

An initial list from NichePCGamer, based on early reporting and community tests, includes:

  • Corsair Force MP600 (Phison E16 controller)
  • Phison PS5012-E12 (reference design)
  • SanDisk Extreme Pro M.2 NVMe (Triton MP28 controller)
  • Fikwot FN955 (MAP1602 + WDS X3 9070 controllers)
  • Kioxia Exceria Plus G4 1 TB (Phison E31T controller)

Additional drives that reportedly vanish but may recover after a reboot:

  • WD Blue SN5000 2 TB (Polaris 3 controller)
  • WD Red SA500 2 TB SATA (Marvell 88SS1074)
  • Corsair MP510 960 GB (Phison PS5012-E12)
  • Crucial P3 Plus (Phison E21T)

These lists are not exhaustive. Firmware variations between OEM modules and retail SKUs mean that a controller family can behave differently across brands. Labs have also observed failures on other controller families, suggesting that the issue is an interaction rather than a single-vendor firmware defect.

Cross‑checking the claims

  • Verified: A reproducible storage regression exists when writing large files on systems with KB5063878. Multiple outlets, including Tom’s Hardware and Guru3D, have independently confirmed that sustained writes of ~50 GB can cause target drives to vanish and potentially corrupt data.
  • Verified: Phison has acknowledged the issue, and Microsoft is collecting telemetry from affected users.
  • Provisional: Silicon Motion’s claim that no SMI controller is affected is based on a forum reply, not an official advisory. Until the company publishes a support bulletin or a validated list of firmware/part numbers, owners of SMI‑based drives should treat the claim as encouraging but unconfirmed.
  • Unverifiable: Any definitive list of safe vs. unsafe SSD SKUs. Community compilations are helpful triage aids, but firmware differences mean lists can mislead unless vendors publish tested validation matrices.

What users should do now

Immediate data protection is the highest priority. The failure mode can result in partial or total file loss on the affected drive.

  1. Back up now: Copy irreplaceable data to another physical drive or a reliable cloud provider. An offline backup adds an extra layer of safety.
  2. Avoid heavy sequential writes: Postpone large game installs, ISO extractions, disk cloning, VM image writes, media exports, or other sustained write operations until fixes are available. The ~50 GB threshold is a practical trigger point observed in community tests.
  3. Identify your drive’s controller and firmware: Use HWInfo, CrystalDiskInfo, or the vendor’s dashboard utility (Samsung Magician, WD Dashboard, Crucial Storage Executive, Corsair iCUE) to capture the model, controller family, and firmware version. Save a screenshot for any support cases.
  4. Monitor official channels: Firmware fixes—if required—will be distributed by SSD vendors through their support utilities, usually with release notes linking the update to the Windows regression. Only apply a firmware update that explicitly addresses this issue and follows the vendor’s instructions.
  5. If the failure occurs:
    - Stop writing to the drive immediately.
    - Capture Event Viewer logs, Device Manager screenshots, and any vendor utility error messages.
    - Reboot only if safe; some drives reappear, others remain inaccessible.
    - Report the incident to Microsoft via the Feedback Hub and to your SSD vendor, attaching the diagnostic logs.

Enterprise admins

Hold KB5063878 deployments in broad rings, run representative sustained‑write stress tests on sample hardware and firmware revisions, and stage rollouts only after vendor advisories and firmware validation. Use WSUS or Intune controls to pause or roll back the update where risk is unacceptable.

Understanding Silicon Motion’s “not affected” claim

The forum reply attributed to Silicon Motion is good news for owners of SMI‑based SSDs, but it must be read with caution. A controller vendor can state that its chips appear unaffected in internal tests, yet branded SSD makers sell thousands of SKUs with varying firmware builds, NAND types, and power delivery designs. A controller family may behave differently across these implementations.

The absence of customer complaints is a positive signal, not definitive proof of universal immunity. It is possible that the tested population differs from the configurations used in community labs, or that affected SKUs are rare. Until Silicon Motion publishes an official advisory with tested firmware revisions and part numbers, users should treat the statement as one input among many.

Why vendor statements are measured

Firmware remediation follows a careful path: reproduce the failure on representative hardware, isolate the firmware component or host interaction causing the hang, produce a firmware fix, test it per branded SKU, and publish tested firmware through vendor tools while documenting affected part numbers. If the root cause is host‑side, Microsoft may issue a Known Issue Rollback (KIR) or a subsequent update to restore previous behavior while firmware updates propagate.

Premature, blanket assertions risk missing rare SKU edge cases and can leave users exposed without an authoritative fix. The goal is correctness and safety, not speed alone.

Short‑term mitigations (with caveats)

  • Split large transfers: Dividing sustained writes into smaller batches (e.g., under 40 GB) can reduce the likelihood of hitting the trigger, though it is not a guaranteed fix.
  • Community registry tweaks: Some advanced users have experimented with limiting HMB allocation via the registry. These workarounds are high‑risk, can degrade performance, and are unsupported. Do not apply them in production without vendor guidance and a full backup.
  • Uninstalling the update: Rolling back KB5063878 via DISM /Remove‑Package is technically possible but can complicate future patching and should only be attempted by experienced users or with enterprise patching team oversight.

How to prepare for fixes

  1. Inventory your drives: Record model, serial number, controller family, and firmware version. This will speed up any support interactions.
  2. Test in a ring: When vendor firmware or Windows updates become available, apply them to a controlled subset of hardware and re‑run sustained‑write tests before wider rollout.
  3. Preserve evidence: If you hit the failure, save logs, screenshots, and utility reports before making any changes. Both Microsoft and vendors have requested telemetry to aid reproduction.

A broader ecosystem lesson

The KB5063878 incident highlights how a seemingly routine security update can expose latent firmware edge cases across a fragmented SSD market. Rapid community reproduction—led by enthusiast test benches and specialist outlets—served as an early warning system, compressing the time between discovery and vendor acknowledgment. At the same time, the slow pace of SKU‑level firmware validation underscores a coordination gap: OS vendors change low‑level semantics that hardware makers cannot pre‑test across every product combination.

Misinformation also became a factor during this incident. Phison found it necessary to denounce forged advisories circulating in the community, which forced the company to pursue legal action. Accurate, verified vendor communications are vital during incidents to prevent unnecessary panic.

Better pre‑release coordination, shared industry test suites for host‑storage interactions, and clearer telemetry pipelines between OS providers and controller vendors would reduce the odds that security rollups trigger high‑impact hardware regressions at scale.

The immediate path forward

For now, the defensible posture is conservative: back up your data, avoid heavy writes on systems with KB5063878 until you’ve validated your hardware in a test ring, and follow only vendor‑published firmware and Microsoft guidance. The Silicon Motion claim, while encouraging, should be verified through official channels before you rely on it.

Storage is too fundamental to gamble with. A few days of caution—backing up and pausing large transfers—can prevent a catastrophic loss of data while the ecosystem fixes itself.