Windows 11 KB5063878 Storage Regression: NVMe SSDs Lose Access on Large Writes

A serious storage regression tied to Microsoft’s August cumulative update for Windows 11 — KB5063878 (OS Build 26100.4946) — has surfaced in the wild: users and independent testers report that sustained, large file writes can cause some NVMe SSDs to stop responding, disappear from Windows, and in a subset of reports leave written files corrupted or partitions inaccessible. The problem is being discussed across specialist outlets and community channels, and the early evidence points to a workload-triggered interaction between the OS update and certain SSD controllers rather than a simple one-off driver crash. The initial stories published by community news sites and tech blogs echo these first-hand test results.

Background / Overview​

Microsoft shipped KB5063878 on August 12, 2025 as the monthly cumulative update for Windows 11, version 24H2 (OS Build 26100.4946). The official release note lists security fixes and general improvements but, as of the package publication, does not enumerate a storage-device failure as a known issue on the Microsoft update page.
Within days of the rollout, multiple independent community tests and reporting outlets reproduced a consistent symptom pattern: during continuous large writes (commonly reported around the 50 GB mark and above) some NVMe SSDs — disproportionately those using certain controller families — can become unresponsive. When the condition occurs the drive may vanish from Device Manager and Disk Management, SMART and controller data may appear unreadable to utilities, and in a fraction of reports files written during the failure window were corrupted or lost. Reboots sometimes restore temporary visibility but do not guarantee that data written in the affected window is intact. (guru3d.com, notebookcheck.net)
This behavior is different from an ordinary blue‑screen crash. It is a storage regression that appears to be triggered by a sustained I/O profile where the OS, storage driver stack, and SSD controller interact under heavy sequential or bulk writes.

---

What the two published reports say​

• The ITC.ua summary provided by the user’s upload highlights the immediate, reproducible symptoms that surfaced after the update and points readers to the community-sourced workarounds and vendor responses. It frames the issue as an urgent warning to users performing large file transfers.
• The gHacks article echoes the community findings and emphasizes that the problem is not universal: “the issue may affect systems with solid state drives (SSD) if a large number of files or a large single file are written to the drives” and that in the worst case the drive becomes inaccessible. gHacks warns readers to take the reports seriously even though the issue originated in community testing and lacks a formal Microsoft “known issue” entry at publication time.

Both articles amplify the same core warnings and are consistent with independent testing coverage published by storage and enthusiast outlets over the same 48–72 hour window. Those independent reports have produced reproducible trigger profiles, controller-model lists, and recovery notes — all of which we summarize and analyze below. (guru3d.com, notebookcheck.net)

---

The technical picture: what appears to be happening​

How the failure shows up​

• Symptom profile: While copying or installing a large set of files (or a single very large file), after ~50 GB of sustained sequential write activity the target SSD becomes unresponsive. The OS may eventually report the drive as missing; SMART/controller info becomes unreadable to utilities; file writes in progress may be incomplete or corrupt. Rebooting sometimes restores access, but the failure often reappears under the same workload. (notebookcheck.net, guru3d.com)
• Reproducibility: Multiple independent tests reproduced the failure profile. Some drives disappeared but remounted after a reboot; other drives required vendor tools or firmware intervention and, in rare user reports, did not reappear reliably without deeper recovery steps. (guru3d.com, notebookcheck.net)

Likely technical mechanisms (current working hypotheses)​

• Controller/firmware edge case: Community analysis points toward controller firmware interaction with new OS buffering or timing behavior introduced (directly or indirectly) by the KB. Several affected drives use Phison-family controllers; community repros also include non-Phison devices, implying the trigger exercises common host-side code paths that expose latent firmware bugs. This pattern is consistent with prior incidents where kernel-level buffering changes exposed controller vulnerabilities.
• Large-write buffering and kernel I/O paths: Sustained sequential writes stress buffering, DMA timing, and the SSD’s internal queueing and metadata handling. If the host changes how it allocates or signals buffers — or its timing expectations shift slightly — a controller that relied on the old timing may enter a stalled state or report malformed responses, which the OS may then treat as an I/O device failure. (guru3d.com, notebookcheck.net)
• HMB / memory allocation confusion (separate but related historical context): Earlier with Windows 11 24H2 there was a distinct but related compatibility incident where Host Memory Buffer (HMB) allocation changes triggered BSODs on some Western Digital / SanDisk DRAM‑less NVMe models. That HMB bug was addressed via vendor firmware updates and was mitigated by registry workarounds for users unwilling or unable to update firmware immediately. It is important to not confl ate that earlier HMB/BSOD incident with this KB5063878 large-write regression — they are different failure modes with separate root causes and remediation paths. (tomshardware.com, neowin.net)

---

Which SSDs and controllers were reported affected (community lists)​

Community testers and several independent outlets produced preliminary lists based on lab reproductions. These lists are helpful as an early warning, but they are community-sourced and should be treated as provisional until vendors or Microsoft publish official confirmations.
Commonly reported or tested models and controllers that have shown vulnerability in reproductions include:

• Drives using Phison controller families (multiple Phison controller models were flagged in community testing). (guru3d.com, notebookcheck.net)
• Specific models reported in early lists: Corsair Force MP600 (Phison E16), drives using Phison PS5012‑E12, Kioxia Exceria Plus G4, SanDisk Extreme Pro M.2 NVMe (Triton MP28 in some tests), various Fikwot and Maxio-branded samples cited in lab reproductions. NotebookCheck and Guru3D published aggregated lists compiled from the community reproductions; those lists vary between labs and are not identical. (notebookcheck.net, guru3d.com)

Caveat: Not every drive using a listed controller will fail in all systems. Results depend on controller firmware revision, NAND configuration, platform BIOS/UEFI settings, motherboard and chipset behavior, driver stack, and the precise workload profile. In short: model lists are indicative, not authoritative.

---

Microsoft’s official position and enterprise impact​

• Official KB page: The Microsoft support page for KB5063878 lists the update and its contents; notably, the published “Known issues” section initially did not include a storage regression entry. Microsoft’s update page instructs standard update handling and includes the usual security advisories.
• Confirmed deployment issue: Microsoft has publicly acknowledged a separate but important installation problem affecting enterprise deployment tools — WSUS and SCCM — where KB5063878 can fail to install with error code 0x80240069. That confirmation accompanied a suggested workaround for enterprise admins. This shows Microsoft is tracking installation problems for the update, though the storage‑device disappearance issue remained a community-discovered regression at the time of reporting.
• Enterprise risk: Beyond data loss risk for end users, the update introduces deployment risk for organizations. Enterprises reliant on automated update channels should pause forced deployment until vendors and Microsoft confirm which hardware/firmware combinations are impacted and supply firmware patches or driver updates. The WSUS/SCCM install failure already requires attention; storage regressions that cause device disappearance on large writes elevate the severity for workstations and servers where mass-data writes are routine. (neowin.net, guru3d.com)

---

Practical, prioritized steps for users and administrators​

The following guidance blends short‑term mitigations, recovery tactics, and medium-term recommendations.

• Pause or delay installation
• If you haven’t installed KB5063878 (or the August cumulative update that corresponds to OS Build 26100.4946), defer it until vendors or Microsoft confirm mitigations or you can validate your drive model is unaffected. Enterprise admins should hold the update in WSUS/SCCM and block automatic deployment for at-risk groups. (support.microsoft.com, neowin.net)
• Back up critical data immediately
• Before any large transfer or if your system already installed the update, make a full file backup of critical data to an external drive or cloud storage. Do not rely on snapshots alone — copy essential files first.
• Avoid sustained large continuous writes
• Where feasible, split large file operations into smaller chunks and avoid a single continuous 50+ GB write session until the situation is clarified.
• Check SSD model, controller, and firmware
• Use vendor tools (e.g., WD Dashboard, Crucial Storage Executive, Corsair SSD Toolbox) or utilities like CrystalDiskInfo to identify your SSD model and controller. If your vendor has posted firmware updates for your model, install them only after reading vendor advisories and backing up data. Firmware updates can mitigate controller bugs but carry a non-zero risk; follow vendor instructions exactly. (tomshardware.com, pcworld.com)
• If already exposed: safe recovery attempts (ordered)
• (a) Graceful shutdown and reboot — some drives return to visibility after a reboot.
• (b) Check Device Manager and Disk Management — if the drive is present offline, do not format; attempt to access with vendor recovery tools.
• (c) Use vendor diagnostic utilities — they can identify controller state and sometimes restore accessibility.
• (d) If recovery tools fail and data is critical, consider professional data recovery — do not perform random low-level writes that may reduce recovery chances.
• Rolling back the update
• If the update is already installed and you observe persistent failures, you can uninstall the cumulative LCU via Settings → Windows Update → Update history → Uninstall updates, or use wusa /uninstall or DISM commands when needed. For enterprise environments, use your management tool to target uninstalls. Note that rollbacks are not a guarantee against corruption caused during the window where the update and the write overlapped; backups are essential.
• For the related HMB / WD early-24H2 BSOD incident (different failure)
• If you are seeing BSODs after upgrading to Windows 11 24H2 and your system uses a WD / SanDisk NVMe without DRAM, vendor firmware updates or the temporary HMB registry workaround fixed many cases in the past. The registry key and the firmware guidance were published and distributed by outlets and vendor support teams; apply correctly and with caution — registry edits can destabilize systems or lower SSD performance. (tomshardware.com, neowin.net)

---

Vendor coordination and verification: what we know and what remains unconfirmed​

• Confirmed facts:
• Microsoft released KB5063878 on August 12, 2025 for Windows 11, version 24H2, OS Build 26100.4946.
• Multiple independent community tests reproduced an SSD disappearance/storage regression during sustained large writes; the workload trigger is typically reported at ~50 GB of continuous write activity. (guru3d.com, notebookcheck.net)
• Community testing highlights Phison-family controllers among affected samples, but tests include other controller families; the problem is not neatly limited to one brand or model. (guru3d.com, notebookcheck.net)
• Microsoft publicly acknowledged an unrelated WSUS/SCCM install failure for the same KB and issued guidance for admins while resolving the install error.
• Items that require vendor/Microsoft confirmation:
• A complete and authoritative list of affected SSD models and firmware revisions (community lists are helpful but incomplete).
• Whether a Microsoft-hosted emergency update, driver update, or firmware update from vendors will be the primary long-term remedy.
• Whether any devices experienced permanent controller damage or irreversible bricking attributable solely to the KB (some reports mention drives that did not reappear; these are being triaged and require vendor forensic confirmation).

Where claims are not yet fully verifiable, they are flagged as such in this piece. Community reproductions are valuable early warning signs — but they do not substitute for official vendor telemetry and coordinated patches.

---

Critical analysis: strengths, risks, and implications​

Strengths (response and ecosystem)​

• Rapid community reproduction and sharing quickly gave direction to users and vendors. Storage and enthusiast sites, along with hands-on testers, produced reproducible test vectors that speed up vendor investigation. (guru3d.com, notebookcheck.net)
• Microsoft’s ongoing engagement with enterprise install issues shows active tracking of update failures; enterprise admins had a published workaround for the WSUS/SCCM install problem within days.

Risks and weaknesses (what the incident exposes)​

• Insufficient cross-supplier pre-release testing coverage for less-common controller/firmware combinations. Windows update rollouts must contend with a vast ecosystem of SSD controllers and firmware variations; this regression demonstrates that even well-scoped updates can expose latent firmware edge cases.
• Potential data integrity loss. When a storage device disappears mid-write there is an inherent risk of incomplete writes or metadata corruption. This is more severe than a mere blue-screen: it can cost users irreplaceable data.
• Enterprise deployment hazards. The simultaneous presence of an install-blocking bug (WSUS/SCCM error) and a storage regression complicates remediation strategies for IT departments — patching one problem may surface another in a different environment.
• Overlap and confusion between different issues. Past incidents (for example, the HMB/WD SN770/SN580 incompatibility with Windows 11 24H2) and the current KB regression risk confusing users and admins unless communications are crystal clear about root causes and corrected versions. (tomshardware.com, guru3d.com)

---

Conclusions and recommended watchlist​

This incident reinforces three immutable rules for reliable system administration and personal computing:

• Backups come first. Always maintain current backups, especially before applying large OS updates or performing bulk data transfers.
• Wait-and-validate for major cumulative updates if you run heterogeneous hardware stacks. Allow a short window for community and vendor feedback, especially in mixed or enterprise environments.
• Keep vendor tools and firmware current — but update firmware only with backups in place and following vendor instructions.

At the reporting time the available evidence points to a reproducible, workload-driven regression after KB5063878 was applied, with community tests implicating certain controller families and sustained-write scenarios around the tens-of-gigabytes range. Microsoft’s KB page and enterprise advisories should be monitored closely; vendors and Microsoft need to publish coordinated advisories and firmware patches to return affected systems to a safe state. In the interim, prioritize backups, delay the KB if you can, and avoid large continuous writes until vendors confirm mitigations and releases. (support.microsoft.com, guru3d.com, notebookcheck.net)

---

If you installed the August 12, 2025 cumulative update and are performing heavy data operations, treat the problem as workload‑sensitive — that is, the vulnerability appears when a specific write profile is exercised. Until formal vendor patches arrive, cautious scheduling and strict backups are the most reliable defenses. The two pieces provided for review (the ITC.ua and gHacks reports) are consistent with the independent reproductions and offer an important early-warning view of the issue; their community-sourced evidence is a vital part of the broader diagnostic picture.

---

Source: ITC.ua Windows 11 update causes SSD crashes while copying many files
Source: gHacks Technology News Latest Windows 11 update reportedly wrecking some SSDs under certain conditions - gHacks Tech News