Microsoft’s August cumulative for Windows 11 (KB5063878) is at the center of a growing, technically consistent set of community reports: after installing the update, some users say NVMe SSDs can “vanish” during large, sustained file writes — sometimes leaving files corrupted, SMART/controller telemetry unreadable, and in a small number of reports drives that do not return to service without vendor intervention. These incidents appear reproducible under a narrow workload profile (long sequential writes in the ~50 GB range on drives that are substantially full) and currently remain community‑reported rather than confirmed by Microsoft as a storage regression. (support.microsoft.com) (guru3d.com) (tomshardware.com)
Microsoft released KB5063878 (OS Build 26100.4946) on August 12, 2025 as the monthly cumulative security and quality rollup for Windows 11 version 24H2. The public KB entry lists the update’s security and quality fixes and states that Microsoft is not currently aware of any issues tied to the package. At the same time, independent testers and enthusiasts began sharing reproducible failure profiles that implicate certain SSD models and controller families in a storage failure that occurs during sustained heavy writes. (support.microsoft.com) (guru3d.com)
Community coverage and logs collected from early testers show a consistent symptom set:
The next 48–72 hours are critical: expect vendor advisories, a Microsoft investigation update if telemetry supports the community findings, and targeted firmware or driver hotfixes if a specific controller/firmware interaction is to blame. Until then, treat the reports seriously, protect your data, and prioritize diagnostic preservation over immediate repair attempts that might overwrite recoverable metadata.
Source: Mashable Windows 11’s latest update may be bricking some SSDs, users report
Microsoft released KB5063878 (OS Build 26100.4946) on August 12, 2025 as the monthly cumulative security and quality rollup for Windows 11 version 24H2. The public KB entry lists the update’s security and quality fixes and states that Microsoft is not currently aware of any issues tied to the package. At the same time, independent testers and enthusiasts began sharing reproducible failure profiles that implicate certain SSD models and controller families in a storage failure that occurs during sustained heavy writes. (support.microsoft.com) (guru3d.com)Community coverage and logs collected from early testers show a consistent symptom set:
- Drives disappear from File Explorer, Device Manager and Disk Management mid-write.
- Vendor utilities lose access to SMART/controller telemetry.
- Reboot may restore visibility in many cases, but data written in the failure window can be partially or fully corrupted.
- Workloads that reproduce the issue are typically sustained sequential writes (large game updates, archive extraction, bulk copies) of roughly 50 GB or more on drives that are at least ~60% full. (notebookcheck.net) (tomshardware.com)
What the evidence shows now
Community reproductions and patterns
Independent testers and multi‑post threads converged on the same trigger profile: sustained sequential writes (often cited near or above 50 GB) on SSDs that are not empty. Testers observed controller utilization spikes and then an abrupt loss of device visibility on the host. The symptom fingerprint (device disappearing, unreadable SMART metrics, corruption of in‑flight files) is consistent across several test systems. Those community collations — taken together — produce a reproducible investigative lead even though they are not an official vendor confirmation. (notebookcheck.net) (guru3d.com)Which drives are implicated (early, community‑sourced lists)
Early lists compiled by testers and niche outlets show a cluster of affected models and controllers — particularly drives using certain Phison controller families — but it is not exclusive to Phison. Reported models vary across posts and test rigs, and community lists are evolving as more tests run. Examples reported by multiple outlets include branded SKUs such as Corsair MP600 and a number of OEM drives built on Phison families; other makes (including drives with Triton and Marvell controllers) appear in some investigator lists too. These lists should be treated as investigative leads rather than definitive recall inventories. (wccftech.com) (notebookcheck.net)What Microsoft has said (and not said)
Microsoft’s public KB page for KB5063878 lists the update’s changes and explicitly states it is not currently aware of any issues associated with the package. That wording remains in place while independent communities publish reproducible reports. Separately, Microsoft did acknowledge and fix a different deployment problem with the same August package — a WSUS/SCCM install failure producing error 0x80240069 — and issued a release‑health update and remediation for that specific enterprise install path. That WSUS/SCCM problem and the storage reports are distinct issues but happened in parallel, which complicates the signal environment for admins and users. (support.microsoft.com) (bleepingcomputer.com)Technical analysis — what likely went wrong
Symptom set points to a host/driver/controller interaction
The pattern — SSDs becoming inaccessible mid‑write with unreadable SMART/controller telemetry — suggests a controller lock‑up or a host‑level storage‑stack regression rather than simple file system corruption on disk. In practical terms, the OS issues an I/O pattern that drives a controller into a state where the controller stops responding or the host stack loses the ability to communicate with it. That can present identically to the OS as if the drive disappeared from the bus. Rebooting reinitializes the controller in many cases, which is why the device frequently returns to life after power cycling. (guru3d.com)Why large sequential writes matter
Large sequential writes stress three subsystems simultaneously: the SSD’s internal cache/DRAM/flash channels, the NVMe controller’s firmware paths for metadata updates, and the OS storage and driver buffers. If a regression (for example in a kernel driver, NVMe stack tweak, or timeout behavior in the update) modifies timing or error‑handling semantics, it can push certain controller firmware implementations to an unrecoverable state under the stress profile. Community reproductions commonly cite ~50 GB of continuous writes as the practical trigger. That threshold is important because it explains why day‑to‑day use rarely reveals the bug while large game downloads, archive extraction, or cloning jobs do. (tomshardware.com)Controller families vs. models
Phison controllers are repeatedly flagged in early reports; their ubiquity in OEM drives and a variety of firmware revisions makes correlation easier for community testers. But several reports include non‑Phison drives as well, which makes a single‑vendor blame premature. The more likely root cause is an interaction surface in Windows’ storage stack (driver or kernel path) that exposes edge cases in certain controller firmware implementations. That also explains the mixed recovery profiles — some drives recover reliably after reboot, others require vendor tools or firmware fixes. (guru3d.com)Caveats and unknowns
- Community tests are compelling but not a substitute for vendor telemetry: Microsoft and SSD manufacturers can observe device‑side logs and host telemetry at scale and may find additional contributing factors (firmware revision, host chipset, BIOS/UEFI NVMe options).
- The anecdotal geographic concentration in some early reporting (initial threads were Japanese users) may reflect early testership and language communities rather than a region‑specific bug. Report volume and geographic distribution can change quickly.
Practical, prioritized guidance for consumers and power users
If you already have KB5063878 installed- Pause any planned large sequential transfers (bulk backups, game installs/updates, disk cloning) until either vendors or Microsoft confirm a fix. Community reproductions show the issue is triggered by sustained heavy writes. (notebookcheck.net)
- Back up any accessible data immediately to a different physical device or cloud storage. The failure profile can corrupt a portion of in‑flight writes; preserve everything you can now.
- Check your SSD vendor dashboard (Corsair, WD, Crucial, Samsung, etc.) and apply vendor firmware updates if one is available — only after a verified backup. Firmware updates historically address controller edge cases but must be applied carefully. (tomshardware.com)
- Capture diagnostics for analysis: event logs (Event Viewer → System), NVMe diagnostic output from vendor tools, and SMART values. If a failure reproduces, preserve logs and avoid further writes to the drive until diagnostics are captured.
- Report the incident through the Windows Feedback Hub and to your SSD vendor’s support channels, including timestamps and collected logs; vendor telemetry helps create a fixable signal.
- Consider pausing Windows updates for the short term if you anticipate large write workloads in the immediate future and your device uses an at‑risk SSD. Use Windows Settings → Windows Update to pause updates for a week and re‑evaluate after vendors and Microsoft publish guidance. If pause is not an option, ensure backups are current before performing heavy I/O. (support.microsoft.com)
- Do not repeatedly reboot hoping to recover files; repeated reinitialization may further overwrite metadata. Instead:
- Record the exact symptoms (Device Manager, Disk Management, vendor utility behavior).
- Capture Event Viewer entries for the time of the failure.
- Use vendor tools (in read‑only or diagnostic mode) to attempt SMART/controller access — sometimes vendor utilities can fetch controller logs after a reboot.
- If the partition is still visible but inconsistent, make a sector‑level image (bit‑for‑bit clone) to a different device before attempting forensic or repair operations. Imaging preserves recoverable data and prevents further in‑place writes during repair attempts.
- Contact vendor support with logs; do not submit the drive for RMA until vendor diagnostics confirm that removal is required.
- Stop writes, back up accessible files now.
- Record Event Viewer and vendor utility outputs.
- Attempt a vendor firmware update only after backup (and after checking vendor advisories).
- If recovery is necessary, create a read‑only disk image before running repair utilities.
- Report to Microsoft Feedback Hub and vendor support with collected logs.
Guidance for IT administrators and enterprise deployments
- Hold mass deployments: If you manage updates via WSUS, SCCM/MECM or similar, stage KB5063878 in a test ring and postpone broad deployment until vendor guidance confirms it’s safe for your fleet or Microsoft publishes a specific mitigation. The August package also produced a WSUS installation error (0x80240069) that Microsoft has since addressed; that fix is separate from the storage reports but demonstrates the update’s real world complexity. (bleepingcomputer.com)
- Increase test coverage: Execute sustained sequential write tests on representative hardware and SSD firmware revisions to reproduce the failure profile in a controlled lab before mass rollout.
- Protect backups: Ensure backup targets are on devices and arrays not using the same SSD models that are under investigation.
- Collect telemetry centrally: If you have endpoint monitoring, capture NVMe errors, controller logs, and storage‑stack events to share with Microsoft and vendors as needed. Centralized telemetry accelerates root cause identification.
What we still need from Microsoft and vendors
- Transparent vendor/MS telemetry sharing: community reports are actionable, but root cause confirmation needs device‑side firmware logs and host kernel traces. Microsoft and vendors should make an authoritative statement if telemetry confirms a regression and publish an official mitigation or fix schedule.
- Firmware advisories (if applicable): if specific controller firmware revisions are implicated, SSD vendors should publish model/firmware tables that indicate which revisions are affected and which are fixed.
- Clear guidance for recovery: vendors should publish do‑it‑yourself diagnostic steps that are safe (read‑only imaging, non‑destructive checks) and escalate paths for recovery and RMA.
Risk assessment — how big a worry is this?
- Likelihood: Low to moderate for the general Windows population right now. The failure mode requires a specific workload (long sequential writes ~50 GB) and is more likely to affect systems with particular SSD models/firmware. If you do not run heavy writes or your storage devices are different, exposure is lower. (tomshardware.com)
- Impact if triggered: High. The event can cause data corruption for files being written at the time and can render the drive temporarily or — in a minority of reports — permanently inaccessible without vendor intervention. That makes the event high impact for creative professionals, gamers updating large game files, backup operators, and anyone who regularly moves large datasets.
- Geographic signal: Early posts showed a cluster in Japan, but later reports and English‑language outlets picked up the issue; geographic skew likely reflects where the earliest testers are active, not a regional codepath. Treat geographic clustering cautiously.
Recommendations — the shortest possible action plan
- Back up now (to an unrelated device or cloud). Do this before attempting any fixes. Priority: immediate.
- If KB5063878 is not installed and you expect to do large writes, consider pausing updates for a short period until vendors or Microsoft publish guidance. Priority: near term.
- If KB5063878 is installed, avoid large sequential writes until firmware/vendor guidance is available; keep Windows Update enabled to receive any future hotfixes. Priority: near term.
- For admins: test the update on representative hardware and pause enterprise rollout until testing passes. Priority: urgent for managed fleets.
- If you see the problem, capture logs, image the drive if needed, and report to Microsoft Feedback Hub and the SSD vendor. Priority: case‑by‑case. (notebookcheck.net) (bleepingcomputer.com)
Final assessment and cautious outlook
The current situation is a textbook example of why staged rollouts, vendor cooperation, and strong telemetry matter. The evidence collected by community testers shows a narrow and reproducible stress profile that can make some NVMe SSDs temporarily or permanently inaccessible after the August 12, 2025 cumulative update (KB5063878), but it remains community‑reported rather than officially declared by Microsoft as a storage regression. Multiple independent outlets and testers have corroborated the same symptom pattern, and Microsoft has acknowledged and remedied a separate deployment defect in the same update set — demonstrating that the package has already produced more than one unintended behavior in the wild. Until vendors and Microsoft publish a joint, authoritative analysis and remediation, the responsible posture for power users and administrators is to back up, avoid heavy sequential writes on potentially affected hardware, pause wide deployment where feasible, and gather diagnostic evidence if the failure occurs. (guru3d.com) (bleepingcomputer.com)The next 48–72 hours are critical: expect vendor advisories, a Microsoft investigation update if telemetry supports the community findings, and targeted firmware or driver hotfixes if a specific controller/firmware interaction is to blame. Until then, treat the reports seriously, protect your data, and prioritize diagnostic preservation over immediate repair attempts that might overwrite recoverable metadata.
Source: Mashable Windows 11’s latest update may be bricking some SSDs, users report