Windows 11 update KB5063878, released August 12, 2025, is triggering a critical storage regression that can make NVMe SSDs disappear from the operating system during sustained, large sequential writes, independent community tests have confirmed. The problem, which manifests after roughly 50 GB of continuous writes, risks corrupting data and leaving drives inaccessible until a reboot—or worse, permanently damaged in rare cases.

Multiple testers, including X user Necoru_cat and Japanese tech site Niche PC Gamer, have reproduced the failure across a range of popular SSDs, particularly those using Phison controllers, though some high-end drives appear immune. Microsoft has not publicly acknowledged the storage issue in the KB’s official documentation, but it has already mitigated a separate WSUS/SCCM deployment failure (error 0x80240069) via a Known Issue Rollback.

The failure footprint: symptoms and triggers

Community reports paint a consistent picture. During heavy sequential write operations—game updates, file copies, media exports, or archive extractions—the target NVMe drive suddenly vanishes from File Explorer, Device Manager, and Disk Management. SMART and controller telemetry become unreadable to diagnostic tools, and files written during the failure window may be corrupted or missing. In most cases, a reboot reinitializes the controller and restores visibility temporarily, but the same workload reliably reproduces the crash.

“Writing more than 50GB of data continuously with an SSD usage rate of over 60% caused their SSD to disappear from the OS,” Necoru_cat reported, noting that the failure occurs every time after a reboot.

The critical trigger appears to be a sustained sequential write that pushes the drive controller’s utilization beyond a threshold—commonly observed around 60% load. After that point, the drive goes offline, and only a full power cycle (or, in some cases, a cold boot) brings it back online. However, a minority of users have reported drives that remained inaccessible even after restarting, requiring vendor intervention.

Which SSDs are affected?

Community-compiled lists and hands-on reproductions show a strong correlation with Phison controller families and some DRAM-less designs. Drives that have appeared repeatedly in aggregated reports include:

  • Corsair Force MP600
  • Phison PS5012-E12 controller-based SKUs (many brands)
  • Kioxia Exceria Plus G4
  • Fikwot FN955
  • SanDisk Extreme PRO M.2 NVMe 3D SSD
  • Adata SP580
  • Kingston SNV2S2000GN

These are investigative leads, not vendor-confirmed recalls. Notably, several high-profile gaming SSDs—like the Samsung 990 Pro and WD Black SN7100—have not exhibited the failure in the same test scenarios, indicating the regression is neither universal across all NVMe drives nor tied to a single brand.

Why a Windows update can break your SSD

Modern NVMe SSDs are tightly integrated subsystems where controller firmware, DRAM (or Host Memory Buffer, HMB), and the host OS storage stack interact at a high frequency. Many DRAM-less SSDs rely on HMB to borrow a small chunk of system RAM for caching mapping tables, while even DRAM-based drives depend on precise timing and command queuing from the host.

When Microsoft changes kernel-level storage drivers, power management policies, or memory allocation behavior—common in cumulative updates—it can expose latent firmware bugs or corner-case controller states that only manifest under stress. The symptom profile here (device disappearance with unreadable SMART) is consistent with either:

  • A host-side regression that inadvertently drives the controller into a fault state, or
  • A firmware edge-case in specific controllers that becomes visible because the host now applies a certain I/O or memory allocation profile.

Both are plausible and not mutually exclusive. Historically, similar issues have required coordinated fixes: SSD vendors publish firmware updates, and Microsoft may release a compatibility block or a kernel patch.

Timeline: how the issue unfolded

  • August 12, 2025: Microsoft releases KB5063878 (OS Build 26100.4946) as the August cumulative security and quality rollup for Windows 11 24H2. Official notes mention only security fixes and quality improvements—no storage known issues.
  • Within 48–72 hours: Community testers and enthusiast outlets begin publishing reproducible reports. Necoru_cat’s thread on X, Niche PC Gamer’s data aggregation, and multiple forum posts converge on the same trigger and affected models.
  • Enterprise deployment hiccup: A separate WSUS/SCCM installation regression (error 0x80240069) prompts Microsoft to apply a Known Issue Rollback and re-release a corrected package for managed deployments. This swift fix highlights Microsoft’s ability to limit enterprise exposure but also underscores that the storage problem has not yet received a public known-issue designation.
  • Ongoing: As of the latest community reports, Microsoft’s official KB page still does not list the NVMe regression as a known issue. Consequently, community observations remain hypotheses pending vendor telemetry and formal root-cause attribution.

The community’s rapid detection: a double-edged sword

The enthusiast ecosystem’s ability to identify, reproduce, and document the failure within days is remarkable. Standardized test scripts (e.g., ~50 GB sequential writes while monitoring controller load) allowed independent verifications across time zones, effectively crowdsourcing a QA process that internal telemetry might have taken weeks to surface.

Yet the community-driven nature of the investigation also introduces biases. Reports skew toward power users who regularly stress-test their storage; casual users may never hit the triggering workload. The model lists, while indicative, lack vendor telemetry and firmware revision details, making it impossible to know the true incidence rate. Over-attribution—blaming the update for pre-existing failures—is a real risk without official confirmation.

What users and admins should do right now

Data protection comes first. If you use an internal NVMe drive for anything important, take these immediate steps:

  • Back up critical data immediately to an external drive or cloud service. Backups are the only guaranteed defense against drive-level corruption.
  • If you haven’t installed KB5063878 and your workflow includes large game installs, video exports, or frequent file transfers exceeding ~50 GB, delay the update. Use Windows Update’s “Pause updates” feature or defer the patch via local policy.
  • If the KB is already installed, avoid sustained large sequential writes on any NVMe drive until you can verify its immunity. Even if your drive isn’t on the community list, caution is warranted, as the list may be incomplete.
  • Monitor your SSD health: Use vendor tools (Corsair iCUE, SanDisk Dashboard, Kioxia Storage Utilities, or universal tools like CrystalDiskInfo/HWiNFO) to check SMART data and firmware versions. Capture logs if anomalies appear.
  • Check for firmware updates from your SSD maker. Vendors have historically released firmware patches for similar OS-induced regressions. However, apply firmware updates only after a full backup and after verifying the update is intended to address this specific issue.

If a drive vanishes during a write:
- Stop further writes immediately. Do not repeatedly reboot, as that may overwrite volatile controller state or cause further corruption.
- Capture diagnostic logs (SMART data, event viewer, device manager screenshots). If the data is critical, consider taking a forensic image before any further actions.
- Contact the SSD vendor’s support team with a detailed reproduction recipe and all captured telemetry. This evidence is crucial for vendor triage.

For enterprise administrators:
- Inventory endpoints for potentially affected NVMe models. Use WSUS/SCCM or MDM controls to pause deployment of KB5063878 on those fleets.
- Schedule intensive I/O tasks on machines that have not yet received the update.
- Monitor Microsoft’s Known Issue Rollback mechanism; if a storage-related KIR is deployed, it can be applied without full update removal.

What to expect from Microsoft and SSD vendors

Resolution will likely follow a familiar pattern:

  • SSD vendors will analyze controller logs from affected users, identify vulnerable firmware revisions, and release updates. They may also issue public advisories with clear firmware version numbers and installation instructions.
  • Microsoft will assess its telemetry for elevated device-offline events tied to build 26100.4946. If confirmed, it can publish a Known Issues entry, deploy a targeted mitigation via KIR, and potentially block the update on systems with affected hardware until firmware is installed.
  • Enterprises should anticipate guidance that allows them to triage and exclude at-risk devices from broad KB deployment. Microsoft’s existing servicing channels (WSUS, SCCM, Intune) already support these exclusions.

Transparent timelines and automated firmware update tools will be key to reducing friction. In the meantime, treat this as a data-integrity risk, not a mere performance glitch.

The bottom line

Converging, reproducible evidence from multiple independent testers strongly indicates that KB5063878 introduces a workload-triggered regression capable of making certain NVMe SSDs vanish and corrupting data. While the exact root cause awaits official vendor and Microsoft analysis, the practical impact for gamers, content creators, and anyone who regularly moves large files is undeniable: drives can disappear mid-operation, and data loss is a real possibility.

The incident also underscores the accelerating tight coupling between OS updates and storage firmware. As SSDs become more sophisticated, even routine security rollups can inadvertently expose hardware edge cases. Until Microsoft and SSD vendors improve pre-release compatibility testing and post-release communication, users are left with the oldest and most effective defense: backup your data before you trust any update.