Installing Microsoft’s August cumulative update for Windows 11 version 24H2 is causing certain SSDs to vanish and become inaccessible during heavy write operations, according to a growing number of user reports. The patch, identified as KB5063878 and released on August 12, 2025, was intended to deliver routine Secure Boot certificate handling and quality improvements for OS Build 26100.4946. Instead, it has triggered a repeatable failure mode that can render drives unreadable, destroy access to SMART telemetry, and in some cases lead to permanent data loss.

The Update and How the Issue Surfaced

KB5063878 arrived as part of Patch Tuesday, automatically rolling out to consumer and enterprise systems alike. Within days, a Japanese PC enthusiast published methodical test logs demonstrating a critical fault. After writing a large block of data—approximately 50GB or more—to NVMe or SATA SSDs that were moderately full (around 60% capacity), the drives would disappear from the operating system. The partition table became unreadable, SMART data inaccessible, and files on the drive were lost. Some drives recovered after a cold reboot; others remained invisible and required advanced recovery steps.

Multiple independent outlets and community sources quickly reproduced the behavior on a selection of drives. The pattern was not uniform: drives using certain Phison controllers exhibited a higher failure rate during sustained sequential writes, while other popular models appeared unaffected. Microsoft’s official KB article did not list this as a known issue at publication, and the company has not publicly confirmed a systemic SSD regression related to this update.

What Users Are Reporting

Reports from affected users consistently describe the following sequence:

  • A large write operation—such as installing a game, extracting a large archive, or moving a multi-gigabyte file—completes or is in progress, and then the target SSD suddenly disappears from Windows.
  • After a restart, Windows either cannot mount the partition or shows the drive as uninitialized. Standard utilities fail to retrieve SMART or NVMe Identify data, indicating the OS has lost communication with the controller.
  • Some users see data corruption: file reads fail, or folders appear empty even though capacity reports used space.
  • A reproducible test case involves writing ~50GB to an SSD that is ~60% full. Not every drive or controller fails, but those that do often fail immediately under these conditions.
  • A preliminary list of affected drives, compiled from user tests, includes several consumer models, with Phison-based devices noted more frequently.

The reports initially concentrated on social platforms and niche tech blogs in Japan, then spread to broader tech press as more anecdotal confirmations surfaced. While the geographic concentration hints at a localized hardware or firmware profile, the issue is not limited to one region.

Technical Symptoms and Their Implications

When SMART or NVMe telemetry becomes inaccessible, it signals that the host OS can no longer communicate with the drive’s controller. This can stem from several root causes:

  • A controller firmware crash or lock-up that stops responding to commands.
  • A kernel-level regression in the I/O stack that mishandles long sequential writes and leaves the device driver in an unrecoverable state.
  • A failing or reset PCIe, USB, or SATA link that renders the drive invisible at the bus level.
  • An interaction between the OS storage stack and vendor-specific drivers that disrupts command sequences, forcing the controller into a protective state interpreted as device removal.

The symptom of drives disappearing specifically during prolonged writes points toward either a controller firmware glitch or a host-side regression affecting how extended sequential operations are processed. Because SMART information stops being readable, the problem is likely at or below the controller level rather than mere file-system corruption.

Why Some Controllers Are Hit Harder

Controller vendors implement distinct firmware strategies for wear leveling, caching, and handling sustained writes. A subtle change in the host’s write-flush ordering, NVMe command semantics, or power-state interaction can trigger unhandled conditions in a subset of firmware stacks. The fact that several affected drives use Phison controllers does not automatically place blame on those controllers—it may simply reflect a common firmware approach that exposes a latent bug in the updated Windows storage stack.

Who Is Most at Risk

Systems most likely to encounter this failure share these characteristics:

  • SSDs at moderate to high capacity (testers used ~60% fullness to reproduce).
  • Workloads involving large, sustained sequential writes—game installs, video editing, large archive extraction, virtual machine images, or backups to a local SSD.
  • Drives with controller firmware variants flagged in early reporting, notably certain Phison-based models.
  • Users without recent backups who perform such write-intensive tasks shortly after installing KB5063878.

Casual users who write smaller files intermittently are far less likely to trigger the edge case.

Immediate Steps to Take

If you have not yet installed the update and wish to minimize risk, consider pausing Windows updates temporarily via Settings → Windows Update → Pause updates, or delay deployment through enterprise tools (WSUS/SCCM).

If you have already installed KB5063878:

  • Back up immediately. Copy critical files to a different physical drive or cloud storage.
  • Avoid large sustained writes to any SSD that might be affected. Performing large installs or transfers on an external drive or cloud storage is safer.
  • Update SSD firmware. Check your drive manufacturer’s toolbox or support site for any firmware updates or advisories that may improve controller robustness.
  • If you encounter a drive disappearance:
  • Power down the PC completely, wait 30 seconds, and cold-start. In some cases, the drive becomes accessible again.
  • If the drive remains invisible, check Device Manager, Disk Management, and Event Viewer for I/O errors or device removal messages.
  • Use vendor utilities to probe the drive. If SMART is unreadable, avoid repeated risky operations and collect logs and screenshots for support.
  • Report the issue through the Windows Feedback Hub and directly to the SSD vendor, including your full system build, SSD model, controller version, and step-by-step reproduction details.
  • For critical data, consult professional recovery services rather than forcing operations that could worsen corruption.

Diagnostic Checklist for Technical Users

  • Confirm your Windows build: run winver or go to Settings → System → About. The affected build is 26100.4946.
  • Record the SSD model, capacity, reported controller, and firmware version using vendor tools or utilities like CrystalDiskInfo.
  • Attempt to read SMART/NVMe Identify data with vendor-specific or standard tools.
  • Check Event Viewer (Windows Logs → System) for entries related to nvme, storahci, disk, or kernel-power around the failure time.
  • If the drive is visible and stable, you can run chkdsk on the partition, but only if the drive is not in a failing state—running chkdsk on an unstable drive can increase data loss.
  • Capture full system logs and attach them to Feedback Hub and vendor support tickets.

Recovery and Long-Term Remediation

  • Firmware updates: Manufacturers may release fixes that improve controller resilience to the specific command sequences causing the issue. Keep vendor utilities up to date.
  • Driver adjustments: In some cases, the problem may be mitigated by switching to a different storage driver (e.g., using the native Microsoft NVMe driver instead of a vendor-supplied one). Monitor vendor guidance for recommended configurations.
  • Official Microsoft patch: The cleanest fix will be a cumulative hotfix or a Known Issue Rollback (KIR) distributed through Windows Update. When Microsoft confirms a regression, such updates typically arrive within days or weeks.
  • Enterprise measures: Organizations should delay broad deployment of KB5063878 via WSUS or SCCM until testing is complete. If the update is already deployed, prioritize systems with write-heavy workloads for rollback or mitigation.

How a Security Update Could Break SSD Communication

Operating system updates routinely touch kernel components, device drivers, and I/O subsystems. Even minor adjustments to how write-back caches are flushed, asynchronous commands are issued, or power transitions are handled can alter the timing and sequencing of NVMe or SATA commands perceived by the controller. Firmware that once worked flawlessly may now encounter an unexpected command sequence and enter a protective state.

Potential root causes include:
- A regression in the OS storage stack that mishandles large sequential writes, sending controllers into states they weren’t designed to handle.
- Changes to queuing or flush semantics that force pathological behavior under sustained writes.
- A side effect of Secure Boot certificate logic that inadvertently conflicts with storage drivers or filter drivers—though the symptom pattern more strongly points to an I/O regression than a Secure Boot flaw.
- A rare interaction between a vendor filter driver (preinstalled by OEMs or SSD toolkits) and the updated kernel.

The non-uniform failure surface—some drives fail instantly while others remain stable—strongly suggests a compatibility issue rather than a mass hardware defect.

What Vendors and Microsoft Are Doing

At least one controller vendor has publicly stated it is investigating the issue and working with partners. Microsoft acknowledged and later resolved a separate enterprise installation problem (error 0x80240069) related to WSUS/SCCM deployments of the update, but has not yet officially confirmed a systemic SSD regression. The company has mechanisms in place—Known Issue Rollbacks and emergency hotfixes—to quickly mitigate confirmed regressions once validated.

For now, the burden is on SSD controller vendors to audit firmware for defensive error handling and on Microsoft to inspect the storage stack changes introduced in KB5063878. Until an official fix is released, users and administrators must rely on the mitigation steps outlined above.

Final Advice for Windows Enthusiasts

This situation underscores a timeless rule: even routine security updates can harbor destructive surprises. The reports are consistent and technically specific enough to merit caution. Back up your data now—regardless of whether you’ve installed the update. Avoid large writes on any SSD that matches the observed risk profile, and keep an eye out for firmware announcements and a forthcoming Microsoft patch.

The problem is real, but it is not a universal bricking event. By acting deliberately—protecting your data, limiting heavy write workloads, and staying informed—you can navigate this patch misadventure without permanent loss.