Microsoft’s August 2025 security update for Windows 11 24H2 is triggering severe storage regressions that can cause NVMe SSDs to vanish mid-write, and in some cases the damage is permanent. Multiple independent testers and industry observers have confirmed that KB5063878—shipped as part of the regular Patch Tuesday cycle—can push certain drives into an unrecoverable state during sustained write operations. As the joint investigation between Microsoft and SSD controller vendors unfolds, users and IT admins are urged to back up data immediately and avoid heavy sequential writes on vulnerable systems.
The update at the center of the storm
KB5063878 is the August 2025 cumulative update for Windows 11 version 24H2, bringing the OS build to 26100.4946. While it addressed critical delays for users signing into new devices, it also introduced a serious storage regression that first surfaced in community forums and technical outlets. Reports describe desktop NVMe SSDs disappearing from Windows during large file transfers, with some drives never reappearing even after a reboot.
The issue is workload-dependent. Testers have found that drives filled beyond 60% capacity and subjected to sequential writes larger than 50 GB are most likely to fail. This pattern has been reproduced across multiple systems, pointing to a host-storage interaction flaw rather than a mere software glitch. The fact that SMART telemetry becomes unreadable in many failure cases suggests a low-level controller lockup, not just a filesystem corruption.
Symptoms and technical clues
The observable symptoms are dramatic. Users report that an SSD will simply drop out of Windows Explorer during a large write—installing a big game, moving a multi-gigabyte archive, or extracting a compressed file. In milder cases, a reboot brings the drive back online, but the same strain will reproduce the error. In severe instances, the drive fails to re-enumerate at all, and data written during the event is corrupted or lost.
Community analysis points to a working hypothesis: the update likely alters host memory allocation or NVMe command timing, creating an unhealthy interaction with SSD controller firmware. DRAM-less drives that rely on Host Memory Buffer (HMB) are especially sensitive, as changes to system memory handling can disrupt the buffer’s reliability. Phison controllers appear disproportionately in failure reports, though this is likely due to specific firmware revisions exposed in the wild rather than a universal hardware defect.
Crucially, uninstalling KB5063878 after a failure does not reliably restore corrupted on-drive metadata. Once the controller enters its unrecoverable state, the damage is often done before any mitigation can be applied.
Which drives are at risk?
No vendor-validated list exists yet, but community testing has identified commonly affected models. These include:
- ADATA SP580
- Corsair Force MP600
- SanDisk Extreme Pro M.2
- Kioxia Exceria Plus G4
- SSDs using Phison PS5012-E12 or InnoGrit controllers
- Fikwot FN955
- Maxio SSDs
The testing also included a WD Blue SA510 2TB SATA SSD, which became completely unrecoverable after the update. While SATA drives are not NVMe, this expansion of the issue underscores the seriousness of the host-level regression.
Risk factors are practical heuristics, not ironclad thresholds: drives more than 60% full, sustained sequential writes above 50 GB, and DRAM-less NVMe designs that lean on HMB. Users performing mass installs or content updates shortly after installing the patch are prime candidates for disaster.
What Microsoft and vendors are saying
Microsoft has acknowledged the reports and is investigating with its storage partners. In a statement to media outlets, the company said it is “aware of these reports and are investigating with our partners.” Phison, the controller manufacturer most frequently mentioned, has confirmed it is working directly with Microsoft to pinpoint affected revisions and deliver fixes.
“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 company said. “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.”
Several SSD vendors have already released firmware updates in response to previous 24H2 issues and are monitoring this situation closely. The expectation is that coordinated firmware advisories and possible out-of-band Windows fixes will follow once engineering teams reproduce and root-cause the behavior.
Immediate steps for home users and enthusiasts
For the next 24–72 hours, the priority is risk reduction. Follow these actions in order:
- Back up now. Copy critical files to a second physical device or cloud storage. Backups are the only reliable defense against on-media corruption.
- Delay KB5063878 if not yet installed. Use Settings → Windows Update → Pause updates, or defer via management tools. This avoids unnecessary exposure.
- If KB5063878 is already installed, avoid heavy writes. Postpone large game installs, bulk media copies, archive extraction, disk cloning, or professional video exports to the suspect SSD. If you must write large data, split transfers into smaller chunks to reduce the chance of triggering the flaw.
- Check for SSD firmware updates now—but back up before flashing. Use vendor toolbox utilities like Corsair iCUE, SanDisk Dashboard, Kioxia Storage Utility, or WD Dashboard. Apply only vendor-provided firmware and follow instructions precisely.
- If you experience a disappearing drive mid-transfer, stop writing, power down, and collect logs. Do not immediately reformat. Capture Event Viewer entries (nvme, stornvme, storahci), SMART data 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 attempting destructive recovery.
Some advanced users have explored registry mitigations to limit or disable HMB allocation, but these carry performance trade-offs and should only be attempted with full backups and a clear understanding of the risk.
Step-by-step: Check if KB5063878 is installed
- Press Win + R, type
winver, press Enter. The About dialog shows the OS build. KB5063878 corresponds to Build 26100.4946. - Alternatively, open Settings → Windows Update → Update history and search for the KB entry. On managed networks, check WSUS/SCCM logs for the package name.
Enterprise guidance for IT admins
Fleet operators must act fast:
- Inventory and pilot: Enumerate endpoints that installed the August rollups. 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: Microsoft has used targeted blocks and out-of-band packages for previous regressions—monitor 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.
Recovery options for drives that fail
If a drive becomes inaccessible:
- Stop further writes immediately. Continued host activity may overwrite recoverable metadata.
- Capture a forensic image if the data is important. Tools like dd or vendor imaging utilities preserve evidence for vendor engineers or forensic recovery specialists.
- Contact the SSD vendor with model, firmware, host OS build, and a step-by-step account plus logs. Vendors require these artifacts to validate root causes and 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.
Risk analysis and what’s uncertain
Three facts and one caution stand out:
- Fact 1: Multiple independent testers reproduced a reproducible storage regression under a defined workload profile after installing KB5063878.
- Fact 2: The issue is workload and firmware dependent—not all SSDs or systems fail, and many users report no issues. Overgeneralized headlines claiming universal “bricking” are unwarranted.
- Fact 3: Microsoft and controller vendors (notably Phison) are actively investigating, and vendor firmware updates or targeted mitigations are likely.
Caution: Community thresholds like “exactly 50 GB” or “60% full” are useful operational heuristics, not absolute failure criteria. Treat them as risk indicators for triage, not definitive technical limits.
Long-term lessons and update hardening
This incident reinforces several best practices:
- Backups are non-negotiable. A 3-2-1 strategy—three copies, two media types, one offsite—remains the gold standard.
- Stage updates in pilot rings that mirror your fleet’s hardware diversity. A small pilot catches platform-specific regressions before mass deployment.
- Advocate for stronger co-testing between OS and controller vendors. Stress tests that simulate sustained sequential writes on high-fill, DRAM-less HMB configurations should be standard.
- Maintain streamlined telemetry and logging processes to accelerate reproduce-and-fix cycles.
Bottom line
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. Monitor official vendor support pages and Microsoft’s Release Health dashboard for authoritative guidance specific to your SSD model and firmware revision. This remains an evolving engineering incident, and the situation will almost certainly change quickly as fixes roll out.