Windows 11 KB5063878: SSDs Vanish Under Heavy Writes — What You Need to Know

Microsoft has acknowledged an active investigation after multiple community researchers, test benches and SSD vendors reported that the Windows 11 August cumulative (commonly tracked as KB5063878, OS Build 26100.4946) can cause certain SSDs to vanish from the operating system during sustained, large sequential writes — a failure mode that can truncate or corrupt files and, in a minority of reports, leave a drive inaccessible without vendor-level intervention. rumulative update for Windows 11 24H2 on August 12, 2025 as part of regular Patch Tuesday servicing. The package was intended to deliver security and quality improvements, but within days a cluster of reproducible reports surfaced: during sustained large writes (commonly reproduced at roughly 50 GB of continuous sequential writes) some storage devices stop responding and disappear from File Explorer, Device Manager and Disk Management. Reboots often restore visibility, but files being written at the moment of failure can be truncated or corrupted.
SSD controller supplier Phison publastry‑wide effects” linked to the updates and said it was coordinating with partners. Microsoft told press it was “aware of these reports and investigating with our partners.” Those vendor and platform acknowledgements elevated the issue beyond forum anecdotes into an active, cross‑industry troubleshooting effort.

---

What users and testers are reporting​

Symptom profile — what vanishes uite begins normally (examples: large game update, disk clone, archive extraction) and then abruptly fails after tens of gigabytes are written, commonly near the ~50 GB mark.​

• The target SSD becomes unresponsive and disappears from the OS topology — it may not appear in File Explorer, Device Manager or Disk Management.
• Vendor utilities and SMART telemetry often stop responding or return unreadable attributes after the event.
• In many cases restores the drive; in a smaller subset of incidents the device remains inaccessible and the partition may show as RAW, or files written during the failure window are corrupted or truncated.

Reproducibility and workload triggers​

Independent hobbyist labs and specialist outlets reproduced a consistent failure profile under a narrow sequential writes on the order of ~50 GB or more, especially on drives that were already substantially filled (community reports commonly flagging >50–60% used capacity). This suggests the bug is workload-sensitive** rather than a random hardware fluke.

Observed scale and distribution​

• The reports are concentrated among enthusiast communities, independent test benches and a range of consumer drives. They are notma universal failure across all SSDs or all machines.
• Community collations indicate clusters around certain controller families and DRAM‑less NVMe designs, but model lists remain provisional and should be treated as investigative leads rather than definitive blacklists.

---

Who’s involved: Microsoft, Phison, and the community​

Microsoft​

Microsoft confirmed it is investigating reports and has been working with partners to identify root causes. The vendor also published ees for other August regressions (notably reset/recovery regressions), illustrating how multiple servicing issues were tracked concurrently during the same update cycle.

SSD controller vendors​

Phison — a major SSD controller supplier — publicly acknowledged it was investigating the effects of the August updates that “potentially impacted several storage devices,” and said it was coordinating withhat acknowledgement accelerated analysis because many consumer drives use Phison controllers, and vendor-level telemetry is required to confirm whether firmware interactions are implicated.

Community researchers and specialist outlets​

Multiple independent hardware outlets and enthusiastic test benches performed controlled reproductions and collated user reports; their early, repeatable findings are the reason the incident escalated quicent. Those tests remain the primary evidence for the workload trigger profile and the practical mitigation steps recommended to users today.

---

Technical analysis — plausible mechanisms​

The pattern of failures reported by testers and vendors points to an interaction between the Windows host storage stack and SSD controller firmware under a sustained I/O stress profile. Several plausible technical mechanismsnd observed in prior incidents:

• Controller firmware lockups: NVMe controllers run complex firmware to manage SLC caching, garbage collection and wear‑leveling. Under long sequential writes the controller may be driven into corner cases that it cannot safely handle, causing it to stop responding to host commands and appear to the OS as if it had vanished. This aligns with the abrupt loss of SMART/controller telemetry observed by testers.
• Host Memory Buffer (HMB) and DRAM‑less drives: DRAM‑less SSDs can rely on the host for metadata via HMB. Changes in host allocation timing introduced by OS updates can destabilize these drives’ metadata handling under heavy write pressure, particularly when SLC caches are exhausted and bacs required. Previous Windows 11 24H2 interactions with DRAM‑less designs produced similar symptoms, and community analyses point to HMB timing as a plausible contributing factor.
• PCIe/Chipset/Platform timing effects: OS-level changes in command submission, queue depth handling, or DMA scheduling can alter the timing seen by controllers. A subtle timing regression on the host can expose latent firmware races in a narrow set of controllers. Several independent commentaries emphasize that d failure space — OS and firmware must be considered together.
• Workload sensitivity (SLC caching exhaustion): Heavily sustained sequential writes deplete fast SLC caches and force the drive to write directly to NAND with concurrent garbage collection. If firmware has unhandled states when the host retains particular behavior, the controller may lock or misreport metadata, producing the disappeaat: these mechanisms are plausible and consistent with community reproductions, but conclusive root cause attribution requires vendor telemetry and cross‑vendor forensic logs. At the time of reporting the investigation was ongoing and no single public, definitive engineering post‑mortem had been published.

---

Risks and practical consequences​

• ** Files being written when a drive becomes unresponsive are at material risk of truncation or corruption. The incident therefore represents more than a temporary nuisance; it can be a data‑loss event for active transfers.
• Drive availability: While most affected devices return after a reboot, a minority of cat remain inaccessible, require firmware reflashes, or present RAW partitions that need reformatting — scenarios that can produce permanent data loss without backups.
• Operational impact for gamers and creators: Large patch downloads, game installations and bulk media transfers are cloads that can reproduce the fault, which is why many early reports came from gamers and content creators. Systems performing large writes (backups, cloning) are similarly at risk.
• Fleet management complexity: Organizations that roll updates broadly without representative htesting risk exposing a small but consequential subset of systems to potential data-loss events. The incident underlines the importance of test rings that include real-world storage hardware and heavy-write workloads.

---

What to do now — step-by-step guidance for users and admins​

The community’s practical guidance coive, evidence-based set of immediate actions. The following numbered steps summarize a defensible response plan.

• Back up critical data immediately from any machine that installed the August update or KB5063878. Backups are the only reliable line of defense against metadata-level or partition damage.
• Avoid sustained, large sequ) on systems that received the update until vendors provide validated firmware or Microsoft publishes a mitigation. That includes deferring large game installs, archive extractions and disk cloning tasks.
• If you’ve experienced a drive disappearance, stop writing to the drive, capture logs (Event Viewer, driver logs), and create a sector image if data is valuable before attempting repairs or reformatting. Imaging preservesdiagnostics and increases chances of recovery.
• Check SSD vendor utilities for firmware updates and advisories. Apply vendor firmware only after imaging and after ensuring the firmware targets the reported issue. Vendor tools can also surface SMART and controform diagnosis.
• For managed environments, stage the update in a pilot ring that specifically includes representative storage hardware and stress tests that simulate large sequential writes before broad deployment. Consider blocking the update temporarily where the risk profile is unacceptal back the update (if necessary)
• Windows allows uninstalling recent cumulative updates through Settings → Windows Update → Update history → Uninstall updates. For enterprise environments, remediation via WSUS/SCCM controls and Known Issue Rollback (KIR)icable. Organizations should coordinate with vendor guidance and prioritize devices with at-risk storage hardware.

---

Recovery and forensic steps for affected drives​

• If the drive returns after reboot, immediately create a full sector image before further writes. This preservr diagnostics and increases the chance of recovering partially written files.
• If a drive is inaccessible, avoid reformatting or initializing it without creating a forensic image first. Many recovery tools and vendor services depend on an unaltered image.
• Engage vendor support with logs and images if data is critical. Vendors can sometimes reflash firmware, perform controller-level resets, or advise recovery paths.
• In production environments, treat any mid‑write drive disappearance as a potential data-loss incident requiring formal incident response: isolate the host, preserve logs, and escalate to vendor engineering teams where necessary.

---

What vendors and Microsoft are doing (so far)​

• Microsoft publicly acknowledged the investigation and engaged with partners to identify scope and impact. Microsoft also pushed targeted out-oer in the same cycle to address other servicing regressions.
• Phison and other controller vendors opened investigations and coordinated with OEMs and drive brands to gather telemetry and test reproductions. Vendor firmware updates and advisories are the most likely remediation route if controller behavior is the root cause.
• Specialist outlets and community test benches published reproducible test sequences and ts; vendors are using those leads to prioritize forensic validation and firmware triage. Community lists are useful for triage but remain provisional pending vendor verification.

---

Critical evaluation — strengths and gaps in current reporting​

Strengths​

• The community t rigorous: independent labs converged on a consistent workload profile (sustained sequential writes) and a consistent symptom set, which is strong evidence for a real host–controller interaction rather than mere coincidence.
• Vendor acknowledgement (Phison) and Micove the issue from anecdote to an industry investigation, making remediation via firmware and OS updates plausible.

Gaps and Unverifiable Claims​

• Publicly available evidence at this stage is largely community-sourced and vendor-confirmation is limited to acknowledgement of investigattative engineering post‑mortem that ties the regression to a specific code path, driver or firmware condition had not been published at the time the community collations were compiled; therefore definitive root-cause attribution remains unverified. This must be explicitly emphasized: community reproducibility is strong evidence, but it is not theted forensic proof.
• Model lists compiled from user reports are useful but inherently noisy: firmware revision, OEM assembly, platform chipset, BIOS/UEFI and even thermal condite whether a given drive reproduces the fault. Treat those lists as investigative leads, not a final compatibility matrix.

---

Longer-term implications and lessons​

• This incident reiterates that modern storage reliability is a co‑engineered property: OS updates, driver behavior, SSD controller firmware and platform firmware (BIOS/UEFI) all interact. Small changes in host timing or resource allocation can expose latent firmware bugs that manifest only under specific workloads.
• For IT teams and system integrators, the practical takeaway is to *test with representative hardespecially when rolling updates that may affect low-level I/O behavior. Test rings must include heavy-write scenarios (large installs, cloning, backup/restore) to catch these edge cases before broad deployment.
• For consumers, the incident reinforces the baseline best practice: keep good, recent bacing critical heavy-write operations immediately after installing system updates until vendor guidance confirms the build is safe for those workloads.

---

Conclusion​

The reports that Windows 11’s August cumulative (KB5063878) can cause some SSDs to vanish during sustained heavy writes are backed by repeatable community tests and vendor acknowledgement that an way. The failure signature — disappearance during prolonged sequential writes commonly around the ~50 GB mark and with drives already substantially used — points to an interaction between Windows’ storage behavior and SSD controller firmware, though a final root cause remained under forensic review.
Practical, immediate actions ack up critical data, avoid large sequential writes on recently updated systems, check vendor firmware advisories, and image affected drives before attempting repairs. For organizations, pause broad deployment where representative storage hardware hasn’t been valtes through a pilot ring that exercises heavy-write workloads.
This remains an active, evolving incident that underscores a persistent truth: Windows servicing changes can surface deep, fragile dependencies in storage stacks. Coordinated telemetry, vendor firmware patches and careful staging are the right path to a stable resolution — but until vendors and Microsoft publish verified remediation, the safest posture is conservative and backup-focused.

---

Source: PCMag UK Microsoft Investigating Reports of SSDs Vanishing After Latest Windows 11 Update

 

[ChatGPT]

Microsoft has opened an investigation after community testers, independent labs and SSD vendors reported that the Windows 11 August cumulative update (KB5063878, OS Build 26100.4946) can make certain storage devices — particularly NVMe SSDs — disappear from the operating system during sustained, heavy writes, sometimes leaving files truncated, partitions unreadable or drives inaccessible until vendor-level intervention. (support.microsoft.com)

Background / Overview​

Microsoft shipped the combined servicing‑stack and cumulative update identified as KB5063878 on August 12, 2025 for Windows 11 version 24H2 (OS Build 26100.4946). The official release notes describe security and quality fixes and state that, at the time of publication, Microsoft was not aware of any issues with the package. The KB also documents that, because the update combines an SSU with the LCU, standard uninstallation via wusa.exe will not remove the SSU portion — removal of the LCU portion requires DISM Remove‑Package with the package name. (support.microsoft.com)
Within days of the rollout, independent testers and users began reporting a reproducible failure fingerprint: during sustained, large sequential writes — commonly observed at or above roughly 50 GB of continuous data — the target drive may stop responding and disappear from File Explorer, Disk Management and Device Manager. Reboots often restore device visibility for some affected units, but files written during the failure window are frequently truncated or corrupted, and a minority of devices remained inaccessible without vendor‑level firmware reflashes, reformatting or RMA. Multiple outlets documented hands‑on reproductions and aggregated community lists of affected models and controller families. (tomshardware.com, notebookcheck.net)

What users and labs are reporting​

Symptom profile (consistent across independent reports)​

• Bulk file transfer or a sustained write (game install, archive extraction, cloning or large backup) proceeds normally and then abruptly stops.
• The target SSD becomes unresponsive and may vanish from the OS topology (File Explorer, Disk Management, Device Manager).
• Vendor utilities and SMART telemetry may become unreadable or return errors.
• A reboot often restores the device temporarily for many drives; a minority remain inaccessible even after reboot.
• Files written during the event are commonly truncated or corrupted. (tomshardware.com, bleepingcomputer.com)

Empirical trigger heuristics (community‑observed)​

Independent testers and Japanese community labs converged on a practical reproduction window: roughly 50 GB of sustained sequential writes on drives that are already moderately used (commonly cited as ~60% capacity or higher). These numbers are empirical heuristics observed in lab runs and community tests, not formal vendor engineering specifications. Treat them as useful mitigation guidance, not absolute thresholds. (tomshardware.com, notebookcheck.net)

Apparent hardware distribution​

Early collations over‑represent drives using Phison controllers — especially some DRAM‑less and mid‑range consumer SKUs — though affected models reported in the wild include units from multiple vendors and controller families. This pattern suggests a workload‑triggered interaction between Windows’ storage stack and certain controller/firmware combinations rather than a single universal hardware defect. Community‑compiled model lists are evolving and remain provisional. Treat per‑model lists as investigative leads until vendors publish formal advisories. (wccftech.com, notebookcheck.net)

Vendor and platform responses​

Microsoft has acknowledged it is investigating the reports and working with partners, while stressing that internal testing and telemetry had not (at first) shown a reproducible increase in disk failure rates in broad telemetry. Microsoft has also asked users experiencing the issue to send diagnostic information via Support for Business or the Feedback Hub to help reproduce and diagnose the problem. (bleepingcomputer.com)
Controller maker Phison publicly confirmed it was investigating and coordinating with partners after being made aware of “industry‑wide effects” linked to KB5063878 and related update KB5062660. Phison said affected controller families were under review and that it would supply updates and advisories to partners as investigations progressed. At least one purported internal Phison document circulated on social channels was later declared falsified by Phison, which has taken legal steps over its distribution; this highlights the risk of relying on unverified leak documents. (wccftech.com, tomshardware.com)
Multiple independent hardware outlets and test benches (Tom’s Hardware, Windows Central, BleepingComputer, NotebookCheck, Guru3D and others) reproduced or aggregated reproductions that matched the symptom profile above, which is why the issue escalated quickly from forum chatter to an industry investigation. (tomshardware.com, windowscentral.com)

---

Technical analysis — plausible mechanisms​

The working hypothesis from community analysis and expert commentary centers on a host‑side change or timing shift that exposes latent firmware race conditions or cache management bugs in certain SSD controllers. Key technical points:

• Modern NVMe SSDs rely on a complex interplay between host drivers, DMA/buffer handling, NVMe command queues, controller firmware, NAND management (SLC caching, DRAM mapping or Host Memory Buffer usage), and thermal/power behavior.
• Sustained, large sequential writes exercise controller metadata updates, SLC cache exhaustion, aggressive garbage collection, and prolonged DMA traffic in ways typical desktop bursts do not. Those stress patterns can reveal edge‑case firmware bugs that were previously dormant.
• DRAM‑less designs that use Host Memory Buffer (HMB) depend on precise host allocations; a regression that affects memory allocation timing, buffer flushing or queue management in the Windows storage stack could destabilize controller behavior under heavy writes.
• Disk disappearance plus unreadable SMART telemetry is consistent with a controller hang or unexpected reset that prevents the host from querying device registers until a hardware-level reset, firmware fix or power cycle occurs. (tomshardware.com)

Important caveat: there is no single, publicly released root‑cause report from Microsoft or the major controller vendors at the time of writing. The above explanation is technically plausible and aligns with repeated laboratory reproductions, but it remains a hypothesis until telemetry and vendor firmware traces are analyzed and published by the parties involved.

---

Scope and risk assessment​

• How widespread is this? The failure mode is not universal. It concentrates in enthusiast/tester communities and in vendor testbeds where heavy write workloads were intentionally executed. That pattern does not mean the risk is purely theoretical; independent labs reproduced the behavior across multiple drives, and some users have reported permanent data loss. (tomshardware.com, bleepingcomputer.com)
• Who is most at risk? Systems that:
• Installed KB5063878 or related preview KB5062660,
• Have SSDs with certain controller families (Phison featured prominently in early reports),
• Are subject to sustained large, sequential writes (50 GB+ in one operation), and
• Have relatively high drive fill levels (community reports ~60% or higher).
• What kind of damage? Predominantly truncated/corrupted files created during the failure and, in a minority of cases, disks that do not reappear until vendor-level recovery or reformat. The worst outcome is unrecoverable data loss if backups are absent. (notebookcheck.net, bleepingcomputer.com)

Given the distribution and reproducibility observed by independent labs, the prudent operational posture is conservative risk management: prioritize backups, avoid heavy writes on recently patched systems, and stage the update across representative hardware before broad deployment in production fleets.

---

Practical mitigations for consumers and administrators​

The following steps synthesize community best practices, vendor guidance where available, and Microsoft’s public KB instructions.

Immediate actions for consumers (ordered)​

• Back up critical data now. Use the 3‑2‑1 rule (three copies, two media types, one offsite). Backups are the only reliable recovery path if metadata or controllers fail. (tomshardware.com)
• Avoid large continuous writes. Split large transfers or install packages into smaller chunks until the issue is resolved (e.g., copy in sub‑50 GB batches where practical). This reduces exposure to the empirically observed trigger. (notebookcheck.net)
• Check if KB5063878 or KB5062660 is installed. Use Windows Update history or the Microsoft Support KB page for build confirmation. Microsoft’s KB confirms the release and build number for KB5063878. (support.microsoft.com)
• If you must roll back the LCU: follow Microsoft’s guidance — the combined package includes an SSU, so uninstalling the LCU requires DISM and the package name; using wusa.exe /uninstall will not remove the SSU portion. Proceed cautiously and ensure backups are in place before removing updates. (support.microsoft.com)
• Gather diagnostics if you see the issue. Collect Event Viewer logs, Reliability Monitor snapshots, the time range of the failure, and SMART/controller data (if readable) and submit a Feedback Hub entry or contact Support for Business — Microsoft has asked affected customers to provide diagnostic reports. (bleepingcomputer.com)

Practical steps for IT administrators​

• Stage the update: Hold KB5063878 in controlled rings (pilot, then broader) until vendor advisories and Microsoft guidance confirm the fix and affected models. Use WSUS, SCCM or Endpoint Manager to control deployment cadence. Community reports also documented a separate WSUS/SCCM install regression (error 0x80240069) tied to the same update cycle; Microsoft used servicing controls to mitigate that issue. (tomshardware.com)
• Inventory storage controllers and firmware: Identify systems with Phison controllers and DRAM‑less designs and prioritize them for testing. Coordinate with OEM/drive vendors for firmware advisories. (wccftech.com)
• Block large write jobs on pilot systems: Avoid mass imaging, large media copies and bulk deployments against pilot devices while investigation is active.
• Collect telemetry: If your environment sees the failure, prioritize vendor case creation and share forensic dumps with Microsoft and the SSD vendor to accelerate root‑cause analysis.

---

Recovery guidance for a vanished drive​

If an SSD disappears mid‑write, follow these cautious steps to preserve forensic value and maximize recovery odds:

• Stop attempting heavy writes to the host and avoid reboot loops that might overwrite residual controller state.
• If the drive vanishes in Windows but is still seen in BIOS/UEFI, do not reformat. Use vendor diagnostic utilities (from the drive manufacturer) to query the device and collect logs.
• Try a clean power‑cycle (shut down, remove power, wait 30 seconds, power up) and check BIOS detection before booting the OS. Some controllers recover after a cold reset; others remain inaccessible until firmware or vendor intervention.
• If the drive is inaccessible and data is critical, contact the drive vendor or authorized recovery service rather than attempting repeated DIY fixes that could worsen the situation.
• If you suspect the update caused the event, gather the Windows Update history, system logs (Event Viewer), and any vendor diagnostic outputs and open a support case with Microsoft and the drive vendor. Microsoft has asked affected users to submit reports and may request dumps to reproduce the fault. (bleepingcomputer.com)

---

Why this matters: systemic lessons​

This incident underscores three recurring truths about modern PC storage:

• Storage is co‑engineered. The operating system, NVMe driver, controller firmware and host firmware (UEFI/BIOS) interact closely. Small timing or buffer changes on the host can expose latent firmware bugs that were previously dormant. (tomshardware.com)
• Representative test rings matter. Organizations should include realistic, heavy I/O scenarios (bulk game installs, clone images, large backup restores) in update validation, not only light desktop tasks, to detect rare but severe regressions.
• Backups and staged deployment remain the most effective defenses. When low‑level storage metadata is at risk, backups are the only reliable recovery path. Conservative update policies for critical endpoints reduce exposure to unexpected platform regressions. (tomshardware.com)

---

What to watch next​

• Microsoft’s release‑health updates and the KB5063878 page for any Known Issue entries or mitigations tied to storage devices. The public KB currently lists the release and build details and initially states no known issues; that can change as Microsoft publishes investigation results. (support.microsoft.com)
• Phison’s firmware advisories and partner bulletins. Phison has acknowledged an investigation and promised updates; vendor firmware fixes are a typical remediation path if controller firmware proves to be the root cause. (wccftech.com)
• Independent test benches (Tom’s Hardware, NotebookCheck, BleepingComputer, Windows Central) for validated reproduction logs and post‑fix verification runs. Multiple independent outlets reproduced the pattern, and those same testbeds will be first to validate vendor fixes. (tomshardware.com, windowscentral.com)
• Watch for corrected/official model lists from vendors rather than ad‑hoc community compilations. Community lists are valuable leads but have included mistaken or unverifiable entries in at least one widely circulated (and later falsified) document. Confirm vendor or Microsoft advisories before taking dramatic actions like wholesale drive replacement. (tomshardware.com)

---

Strengths and risks in the current public signal​

• Strengths: multiple independent reproductions from reputable hardware test benches and hands‑on community labs give the reports technical weight beyond single anecdotes. Vendor engagement (Phison) and Microsoft’s public acknowledgment and request for diagnostics indicate a coordinated investigation is underway. (tomshardware.com, bleepingcomputer.com)
• Risks: community model lists and specific thresholds (50 GB, 60% fill) are observational and may not generalize across firmware revisions, platforms, or host BIOS/UEFI settings. Relying on leaked or unverified documents can spread misinformation — Phison has already disowned a falsified “internal” summary that circulated online. Until coordinated vendor telemetry and a formal root‑cause report are published, conclusions about universal blame or permanent hardware damage are premature. (tomshardware.com, notebookcheck.net)

---

Bottom line​

The combination of repeatable reproductions, independent hardware testbed results and vendor acknowledgement is sufficient reason to treat the KB5063878 storage reports as a real, actionable risk: back up now, avoid sustained heavy writes on systems that received the August 12 cumulative update, and stage any broad rollout until vendors and Microsoft publish validated mitigation steps.
Practically, that means administrators should throttle the KB deployment into controlled pilot rings, inventory affected controller families, and prepare to coordinate firmware updates or targeted patches from drive vendors. Consumers should prioritize backups, split large transfers and consider holding the update on non‑critical systems until further guidance is available. Microsoft and Phison’s engagement is encouraging, but until a formal technical fix and verified validation appear, conservative hygiene and staged deployment remain the safest approaches. (support.microsoft.com, wccftech.com)

---

(If experiencing the problem, collect logs and vendor diagnostics and file a detailed report with Microsoft Support or via the Feedback Hub — Microsoft has asked for affected users to provide diagnostic information to assist the investigation.) (bleepingcomputer.com)

---

Source: PCMag Australia Microsoft Investigating Reports of SSDs Vanishing After Latest Windows 11 Update