Windows 11 24H2 KB5063878 Storage Regression: SSDs Disappear Under Heavy Writes

The August cumulative for Windows 11 24H2 (KB5063878) has been linked by multiple independent testers and specialist outlets to a reproducible storage regression that, under sustained large write workloads, can make some NVMe SSDs — and a small number of HDDs in isolated reports — disappear from Windows and, in a minority of cases, suffer data corruption or permanent loss.

Background / Overview​

The package in question is the August 12, 2025 cumulative update for Windows 11 version 24H2 (OS Build 26100.4946), released as KB5063878 and containing fixes rolled up from KB5062660. Microsoft’s official KB page lists standard security and quality improvements and, at the time of initial reports, did not list the storage behavior as a known issue.
Within days of rollout, hobbyist testers and community researchers documented a highly repeatable failure profile: when a target drive is subjected to sustained sequential writes — commonly in the ballpark of ~50 GB or more while the drive is moderately full (~60% used) — the drive can stop responding, vanish from File Explorer and Device Manager, and become unreadable to SMART/utility tools. A reboot sometimes restores visibility; in other cases the device is inaccessible even after reboot and files written during the event are corrupted or missing. Independent test aggregations and hands-on reproductions have echoed this symptom set. (tomshardware.com, notebookcheck.net)
Several outlets and community labs highlighted that drives using Phison controllers were over-represented in early failure lists, and some DRAM-less designs and InnoGrit-based models also surfaced in reproductions. That pattern elevated the incident into an industry investigation rather than isolated anecdotes — Phison publicly acknowledged it was investigating the reports and said it was coordinating with industry partners to identify affected controller families. Microsoft, meanwhile, had not published a storage-specific known issue in the KB page when the problem first circulated. (bleepingcomputer.com, windowscentral.com)

---

What users are actually experiencing​

• Symptom profile: a long, continuous write (game install, archive extraction, large backup, or tens of gigabytes of files) begins normally and then the target drive either stalls or disappears from Windows entirely. Tools that normally query SMART or NVMe telemetry return errors or timeouts. Reboot sometimes brings the device back, but the same heavy-write sequence can reproduce the failure. (tomshardware.com, notebookcheck.net)
• Repro trigger: community reproductions converge on sustained sequential writes roughly in the 50–100 GB range and cases where drives are at moderate-to-high fill levels (often cited near 60% capacity). These numbers are empirical observations from user tests, not formal thresholds guaranteed by vendors. (notebookcheck.net, tomshardware.com)
• Controller over-representation: Phison controllers (across several families) appeared frequently in community test lists, and DRAM-less variants were repeatedly flagged as showing failures at lower write volumes. InnoGrit controller reports and a smattering of HDD model appearances have also been mentioned in collated reproductions. These are early investigative leads rather than vendor-validated, universal lists. (tomshardware.com, notebookcheck.net)
• Outcomes: many affected drives recover after a reboot; some return with partial corruption on the volumes involved in the transfer; a minority of reports describe drives that remain inaccessible and require vendor intervention, RMA, or professional recovery services. The permanence of damage has not been quantified by vendors at the time of reporting. (bleepingcomputer.com, tomshardware.com)

---

How credible is the evidence?​

The signal that propelled this from forum chatter into mainstream coverage meets three credibility conditions: reproducibility, independent replication, and vendor acknowledgement.

• Reproducibility — multiple independent testers reproduced the same operational fingerprint (device disappearance during sustained writes).
• Independent replication — specialist outlets aggregated and validated those reproductions across different test rigs and drives. (notebookcheck.net, tomshardware.com)
• Vendor-level acknowledgment — Phison confirmed it was aware of “industry‑wide effects” associated with KB5063878/KB5062660 and said it was working with partners to identify affected controller families; that elevates the risk from isolated hardware failures to an interaction worth industry investigation.

At the same time, formal telemetry and root-cause attribution (host OS memory management vs. controller firmware bug vs. combined race condition) remained incomplete in public documentation at first. That means some claims in circulation — for example, that every Phison-equipped SSD will fail under these conditions — are not supported by the available evidence and should be treated cautiously.

---

The most plausible technical explanation (what engineers are looking at)​

Modern NVMe SSDs are complex co‑engineered systems: NAND flash, controller firmware, optional DRAM, the host NVMe driver, and OS memory/buffering policies all interact. Two technical elements are central to current hypotheses:

• Host Memory Buffer (HMB) usage and DRAM-less designs: DRAM-less SSDs often rely on HMB to borrow a small region of system RAM for mapping tables and caching. Changes in OS allocation, timing, or buffering behavior can alter the host/firmware interaction surface and reveal latent controller firmware race conditions or memory-handling edge cases.
• OS‑buffered memory and drive-cache interactions: early reproductions and tester commentary raised the possibility of a memory-leak or buffer mismanagement in an OS-buffered region that drives a controller cache into an unrecoverable state. That hypothesis fits the observed fingerprint (controller telemetry unreadable, device disappears mid-write) but remains an engineering hypothesis until vendor telemetry or kernel-level traces confirm it.

Put simply: sustained sequential writes exercise controller caching, metadata management and garbage collection paths for longer than typical desktop bursts. If the host changes timing or memory allocation semantics (as an OS update can), the controller firmware may encounter conditions it wasn't exercising in pre-release testing. That mismatch can produce hangs or protective lockups. Multiple teams across Microsoft and SSD vendors must therefore coordinate to pin down whether the fix lives in firmware, driver code, or an OS-side mitigation.

---

Who’s responding and what to expect next​

• Phison: publicly acknowledged the reports and said it was collaborating with partners to review controller families that may be involved. That acknowledgement indicates Phison is collecting telemetry and preparing partner advisories or firmware fixes where necessary. Firmware changes are the normal remediation path when controllers are at fault, but they must be validated per SKU before broad distribution.
• Microsoft: the KB entry for KB5063878 currently lists no storage-related known issues and documents the package contents and delivery method. Microsoft did address a separate WSUS/SCCM install error for the same package — indicating the company monitors deployment telemetry and can apply Known Issue Rollback (KIR) or targeted mitigations when necessary. If root-cause analysis shows host behavior is a contributor, Microsoft could release an OS patch or targeted safeguard.
• SSD vendors (Corsair, Kioxia, WD, SanDisk, Kingston, ADATA, Seagate, etc.): vendors will be the distribution channel for firmware updates and advisories. Expect vendor-specific firmware and guidance (and RMA support) rather than a single, direct update from controller designers to end users. Firmware rollouts may be staged by SKU and may require vendor utilities to apply.

Realistically, a formal fix path can take days to weeks depending on the complexity of reproducing the bug in the lab, crafting firmware, validating across SKUs and platforms, and distributing updates via vendor tools. Microsoft and vendors may coordinate a two‑prong approach: vendor firmware where the controller is at fault, and a host-side mitigation (or upgrade block) if host behavior requires changes.

---

Practical guidance — immediate actions for consumers and IT teams​

The single most important action for any user is to secure data. The following checklist is conservative and practical.

• Back up critical data now. Use the 3-2-1 rule (three copies, two media types, one off-site) if possible. Backups are the only guaranteed defense against firmware-level corruption.
• If you have not installed KB5063878 / KB5062660 and you routinely perform large sequential writes (game installs, large archive extraction, video exports, disk cloning), consider delaying the update until vendors or Microsoft publish a mitigation.
• If you already have the updates installed, avoid writing very large files (> ~50 GB) in a single continuous operation to at‑risk drives (Phison, DRAM-less SKUs, or models flagged in community lists) until vendor guidance is available. Splitting transfers into smaller batches reduces immediate risk.
• Inventory endpoints: map SSD models, controller types, and firmware versions across critical machines. Prioritize DRAM-less devices and those listed in early reproduction logs for extra caution. Use vendor utilities and CrystalDiskInfo/smartctl to record firmware/SMART data.
• If a drive disappears during a transfer, stop writing to the drive, power off the host, and move the drive to a quarantine system for imaging. Preserve logs and device firmware/utility outputs for vendor support or forensic analysis. Imaging is essential if the data is critical.
• Avoid ad-hoc registry tweaks or community “HMB disable” hacks in production unless you can fully test and rollback; such mitigations can reduce performance and carry their own risks. Treat them as desperate stop-gaps for advanced users who understand the trade-offs.

For administrators: use WSUS/SCCM/MEM/MDM controls to hold KB5063878 back from at-risk fleets until vendor validation. Microsoft has used Known Issue Rollback and targeted policies in the past to mitigate problematic updates; monitor Release Health and vendor portals for coordinated guidance.

---

If a drive is already unreadable​

• Do not reformat or run write-heavy recovery tools on the device. Continued writes can worsen firmware-level corruption.
• Image the drive immediately with a forensic tool (ddrescue, FTK Imager, vendor imaging tools) to capture whatever remains. That image preserves evidence for vendor RMA or professional recovery.
• Capture system logs (Event Viewer, NVMe driver traces), note the exact Windows build number and KB install timestamp, and record firmware versions and vendor tool outputs. Vendors may require these data points to reproduce the failure and to authorize RMAs.
• Contact the device vendor support with the collected artifacts. For critical data, engage professional recovery services before applying experimental fixes.

---

Evaluating the risks — how worried should you be?​

The phenomenon matters for three reasons:

• Data impact: even if only a small percentage of drives are affected, the potential for permanent data loss makes the event high-impact for affected owners. Backups remain the single most reliable defense.
• Scale: Phison is a large controller supplier whose silicon appears across many mainstream and value-priced NVMe SKUs. That ubiquity means the potential exposure footprint is wide — but ubiquity does not equal inevitability; the failure requires a specific workload and certain firmware/host conditions that do not occur universally.
• Systemic fragility: the incident is a clear reminder that modern PCs are co‑engineered systems and that OS changes can expose latent firmware bugs. This kind of host-controller interaction has precedent and is typically addressed by coordinated firmware patches and, where necessary, host-side mitigations.

Bottom line: treat the situation seriously and apply conservative mitigations — but also avoid sensationalizing every anecdote as a universal hardware death sentence. The evidence supports a targeted compatibility or interaction problem, not a universal recall.

---

What vendors and Microsoft are likely to do (and what to watch for)​

• Phison and SSD vendors will audit crash reports and produce firmware updates for affected controller families when they can reproduce and fix the bug. Firmware fixes will be vendor-specific and delivered through vendor utilities or support channels.
• Microsoft may either publish a Known Issue entry on the KB page, roll out a targeted mitigation, or coordinate a temporary upgrade block for specific hardware IDs if host behavior requires it. Historically, Microsoft has used such mechanisms to limit the blast radius of platform regressions while vendors distribute firmware.
• Expect vendor advisories, firmware changelogs, and coordinated guidance in the hours-to-weeks after an industry acknowledgement. When firmware arrives, test it in a controlled environment before broad deployment and ensure verified backups are in place.

---

Red flags and unverifiable claims (what to be cautious about)​

• Any claim that “all Phison drives will fail” should be treated as false until vendor telemetry proves it. Reports show over-representation, not universality.
• Numbers such as “exactly 50 GB” and “60% full” are practical heuristics from reproductions, not hard thresholds. They are useful for risk management but not definitive failure criteria. Treat them as indicators, not absolutes.
• Early lists of affected SKUs coming from community tests are investigative leads that help triage risk; they are not the same as vendor-confirmed affected SKU lists. Use them to prioritize testing and backups, not to assume universality.

---

The broader lesson for Windows and storage ecosystems​

This incident is a repeat of a familiar pattern: an OS or driver change alters timing, memory allocation, or buffer management and thereby exposes firmware edge-cases that were not previously exercised in the field. Fixing these problems requires cooperation across OS vendors, controller designers, and SSD integrators — plus disciplined update staging and robust backups from end users.
The episode should re-focus engineering teams on holistic pre-release stress testing that includes prolonged sequential I/O, high-fill scenarios, and HMB/DRAM-less permutations across modern host stacks. For IT teams, it underscores the value of conservative rollout rings: keep a tested pilot group, use rollback and blocking policies, and maintain a current inventory of storage firmware and controllers.

---

Practical checklist — immediate next steps (condensed)​

• Back up irreplaceable data immediately to independent media or cloud.
• Delay KB5063878 installation on systems that regularly perform large sequential writes or use DRAM-less/Phison-equipped SSDs.
• If already updated, avoid large single-shot transfers (> ~50 GB) and split workloads into smaller batches until vendor guidance arrives.
• Inventory SSD models and firmware; prioritize at-risk SKUs for testing.
• If a drive disappears, stop writes, image the drive, collect logs, and contact vendor support.

---

The evidence assembled from community reproductions, specialist outlets, and vendor acknowledgements establishes a clear, actionable risk: certain Windows 11 24H2 updates correlate with an operational fingerprint that can render certain storage devices inaccessible under heavy write workloads. The immediate and defensible posture for consumers and administrators is conservative — secure backups, delay heavy writes on suspect hardware, inventory storage firmware, and await coordinated vendor and Microsoft mitigation. Industry remediation will likely be firmware updates and targeted host mitigations; until they arrive, treat large sequential transfers on recently patched systems with caution. (support.microsoft.com, bleepingcomputer.com, tomshardware.com)

---

Source: PC Perspective Be Gentle With Phison Powered SSDs Until The Latest Windows 11 24H2 Patch Stops Executing Them - PC Perspective