Windows 11 24H2 KB5063878 Storage Regression: Protect NVMe SSDs Now

Microsoft’s August cumulative (KB5063878) for Windows 11 24H2 has been linked by multiple independent testers and industry observers to a storage regression that can make some NVMe SSDs disappear during heavy writes — sometimes temporarily, sometimes with irrecoverable damage — and the safest path for now is conservative: back up, avoid large sequential writes, pause or delay the update on vulnerable systems, and follow vendor guidance until Microsoft and SSD makers publish coordinated fixes.

Background / Overview​

Microsoft shipped KB5063878 (the August 2025 cumulative for Windows 11 version 24H2, OS Build 26100.4946) as part of its regular Patch Tuesday cycle. Shortly after deployment, community testers and a number of tech outlets began reporting a troubling pattern: systems with certain NVMe SSDs — notably many using Phison controllers and some DRAM‑less designs — would vanish from Windows during large, sustained write operations (installing big games, moving 50+ GB of data, large archive extraction). Some drives reappeared after a reboot; others refused to re-enumerate and showed signs consistent with controller-level failure. (windowscentral.com, tomshardware.com)
Independent reproduction attempts indicate the failure is workload‑dependent: drives that are more than ~60% full and subjected to tens of gigabytes of continuous writes are most at risk. That triggered vendor statements and a joint investigation between Microsoft and SSD controller vendors such as Phison. Microsoft has asked affected customers to report specifics while investigating, and Phison has confirmed it’s working with partners on the issue.

---

What’s actually happening: Symptoms and technical clues​

The observable symptoms​

• Drives disappear from Windows during a large write operation (50 GB+ reported in tests). In milder cases they return after a reboot; in severe cases they do not reappear at all.
• SMART/telemetry becomes unreadable in some failures, which is a sign the problem sits at or below the SSD controller level rather than only being a file‑system glitch.
• Data that was mid‑write when the event occurred can be corrupted or lost; uninstalling the Windows update afterward does not reliably restore corrupted on‑drive metadata.

Probable mechanics (what the evidence points to)​

The community’s working hypothesis centers on how the update alters host behavior — particularly memory/caching or NVMe command timing — and how that interacts with SSD controller firmware and caching strategies (including Host Memory Buffer or HMB on DRAM‑less drives). The result: sustained write patterns can put the controller into an unhandled or unrecoverable state. Because the symptoms include unreadable SMART and controller telemetry, the fault appears to be more than just a user‑level driver bug. Independent analyses and vendor statements point to a host/firmware interaction rather than a single brand’s hardware defect.

Why Phison controllers and DRAM‑less drives are over‑represented​

• DRAM‑less drives rely on HMB (Host Memory Buffer) and are therefore more sensitive to host memory allocation and timing changes.
• Phison controller families show up often in community reproductions — not because Phison universally fails, but because some firmware revisions exposed in the wild are more likely to encounter the problematic host behavior. This over‑representation is a signal, not an absolute.

---

Which models and workflows are most at risk​

No exhaustive, vendor‑validated “all‑affected” list exists yet; reports have identified a mix of consumer models across manufacturers. Commonly named examples from community tests include:

• ADATA SP580, Corsair Force MP600, SanDisk Extreme Pro M.2, Kioxia Exceria Plus G4, and other drives with Phison or certain InnoGrit controllers.

Key risk factors (practical heuristics drawn from reproducibility reports):

• Drives more than ~60% full.
• Sustained, large sequential writes (single transfers of ~50 GB or more).
• DRAM‑less NVMe devices that rely heavily on HMB.
• Systems that perform mass installs or content updates shortly after installing the KB. (tomshardware.com, windowscentral.com)

Important caveat: these thresholds are heuristics from community reproductions, not immutable hardware limits. Treat them as practical risk-management rules, not ironclad failure criteria.

---

What Microsoft and vendors are saying and doing​

• Microsoft acknowledged it is investigating reports, asked customers to submit feedback and logs, and told press it has not yet been able to reproduce an increase in disk failure telemetry on up‑to‑date test systems. Microsoft is coordinating with storage partners as part of the probe.
• Phison publicly stated it is working with Microsoft and partners to identify affected controller revisions and to produce fixes where necessary.
• Several SSD vendors have already issued firmware updates in response to related 24H2 issues in the past and are monitoring the situation; vendor reaction times and the scope of firmware fixes will vary by model and channel.

The upshot: this is an active investigation. Expect vendor firmware advisories and/or targeted Microsoft mitigations (known issue entries, upgrade blocks, or out‑of‑band fixes) once engineering teams reproduce and root‑cause the behavior.

---

Immediate, practical steps for home users and enthusiasts​

The next 24–72 hours are about risk reduction rather than heroics. Follow these prioritized actions:

• Back up now.
• Copy critical files to a second physical device or to cloud storage. Backups are the only reliable defense against on‑media corruption.
• Pause or delay installing KB5063878 if you haven’t yet.
• Use Settings → Windows Update → Pause updates, or defer the update via your management tool. This avoids unnecessary exposure until vendor guidance appears.
• If you already have KB5063878 installed: avoid heavy write operations.
• Postpone large game installs, bulk media copies, large archive extraction, disk cloning, or professional video exports to the suspect SSD. Splitting transfers into smaller chunks reduces the chance of triggering the failure.
• Check for SSD firmware updates now — but back up before flashing.
• Vendor toolbox utilities (Corsair iCUE, SanDisk Dashboard, Kioxia Storage Utility, WD Dashboard) can show firmware and apply updates. Only apply vendor‑provided firmware and follow instructions exactly. Firmware flashing itself carries a small risk, so have a verified backup first.
• If you experienced a disappearing drive mid‑transfer: stop writing, power down, and collect logs.
• Do not immediately reformat. Capture Event Viewer entries (nvme, stornvme, storahci), SMART with CrystalDiskInfo or smartctl if readable, and use vendor tools to snapshot drive status. If the drive remains invisible, contact vendor support and consider a forensic image before destructive recovery attempts.
• Consider uninstalling the update only as a temporary mitigation where appropriate.
• On consumer systems you can go to Settings → Windows Update → Update history → Uninstall updates and remove the LCU. Be aware that combined SSU+LCU packages and servicing stack changes can complicate uninstallation; for advanced cases consult vendor guidance or Microsoft support before removing servicing stack components.

---

Step‑by‑step: How to check whether KB5063878 is installed​

• Press Win + R, type winver, and press Enter — the About dialog shows the OS build (KB5063878 corresponds to Build 26100.4946 in community reporting).
• Alternatively, open Settings → Windows Update → Update history and search for the KB entry. On managed networks, check WSUS/SCCM logs for the package name.

---

When to consider advanced mitigations (with caution)​

Some advanced users proposed registry or driver mitigations that limit or disable HMB allocation as a temporary workaround. These carry trade‑offs — notably reduced SSD performance — and should only be attempted with full backups and an understanding of registry risk.

• Example registry path discussed in community threads: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device (and other storport/stornvme parameters). Community posts cautioned that registry edits are emergency mitigations and may not solve every manifestation of the issue. Use only if you are comfortable with potential side effects and have backups.

---

Recovery options for drives that fail​

If a drive becomes inaccessible:

• Stop further writes. Continued host activity may overwrite recoverable metadata.
• Capture a forensic image if the data is important. Use tools like dd or vendor imaging utilities; imaging preserves evidence for vendor engineers or forensic recovery specialists.
• Contact the SSD vendor and provide model, firmware, host OS build, and a step‑by‑step account and logs. Vendors often require these artifacts to validate root causes and to process RMAs.
• If warranty or vendor-level fixes are not possible and data is critical, engage a professional data‑recovery service; do not attempt low‑level fixes that could further damage the controller’s internal metadata.

---

Enterprise guidance (IT admins and fleet operators)​

• Inventory and pilot: enumerate endpoints that installed the August rollups and prioritize representative hardware, especially DRAM‑less NVMe and Phison-equipped devices. Stage updates through pilot rings before broad deployment.
• Pause large automated I/O jobs: hold imaging, content pushes, and large file distribution pipelines on recently updated endpoints until vendor fixes are validated.
• Use WSUS/SCCM controls and Known Issue Rollbacks where appropriate: Microsoft has used targeted blocks and OOB packages for other August regressions — track the Release Health dashboard and the KB page for formal mitigations.
• Prepare logging and runbooks: collect NVMe traces, Event Viewer logs, and drive SMART dumps to expedite vendor troubleshooting and RMA processing.

---

Risk analysis and what’s uncertain​

There are three important facts and an important caution:

• Fact 1: Multiple independent testers reproduced a reproducible storage regression under a defined workload profile after installing KB5063878/related August updates. (tomshardware.com, guru3d.com)
• Fact 2: The issue is workload and firmware dependent — not all SSDs or systems fail, and many users report no issues. Over‑generalized headlines that claim universal “bricking” are unwarranted.
• Fact 3: Microsoft and controller vendors (notably Phison) are actively investigating; vendors may release firmware updates and Microsoft may deploy targeted mitigations.

Caution: community thresholds such as “exactly 50 GB” or “60% full” are useful operational heuristics derived from reproducibility tests, not absolute failure thresholds applicable to every drive. Treat these numbers as risk indicators for triage, not definitive technical limits.

---

Long‑term lessons and how to harden update strategies​

• Backups are non‑negotiable. The most reliable protection for local data is an independent backup strategy (3‑2‑1: three copies, two media types, one offsite).
• Stage updates in pilot rings that mirror the hardware diversity of your fleet. A small pilot catches platform-specific regressions before mass deployment.
• Improve co‑testing between OS vendors and controller vendors, including stress tests that simulate sustained sequential writes on high‑fill drives and DRAM‑less/HMB permutations. The rise of host‑assisted features increases the need for cross‑vendor validation.
• Maintain streamlined telemetry and logging processes for rapid reproduce-and-fix cycles. Timely, detailed vendor logs speed up root cause analysis and reduce RMA cycles.

---

Bottom line — what to do right now​

• Back up irreplaceable data immediately.
• If you haven’t installed KB5063878, consider delaying the update until vendors and Microsoft publish explicit guidance or fixes.
• If you have the update installed, avoid heavy sustained writes to any NVMe that might be susceptible; check firmware and vendor advisories.
• If you experience a disappearing drive during a transfer: stop, power down, preserve logs, and contact the SSD vendor before attempting destructive recovery steps.

This remains an evolving engineering incident. Until Microsoft and SSD vendors publish coordinated diagnostics and targeted fixes, the prudent posture is conservative: protect data first, delay risky operations second, and apply vendor fixes only after backups and validation.

---

The situation will probably change quickly as vendors and Microsoft iterate on firmware and host mitigations; monitor official vendor support pages and Microsoft’s Release Health for the authoritative guidance for your specific SSD model and firmware revision.

---

Source: Wonderful Engineering A Windows Update Is Breaking Some SSDs - Here Is What You Should Do To Avoid It