Windows 11 KB5063878: SSDs Vanish Under Heavy Writes, Data Risk

Microsoft and SSD vendors have opened an investigation after multiple independent testers and users reported that the August 12, 2025 Windows 11 cumulative update (KB5063878, OS Build 26100.4946) can cause some NVMe and SATA drives to stop responding, vanish from the operating system, and — in a smaller number of cases — return with corrupted or inaccessible data following sustained, heavy write activity. (support.microsoft.com) (tomshardware.com)

Background / Overview​

Microsoft shipped KB5063878 (OS Build 26100.4946) on August 12, 2025 as the regular monthly cumulative (LCU) for Windows 11 version 24H2. The public KB entry lists security and quality improvements but initially stated that Microsoft was “not currently aware of any issues with this update.” (support.microsoft.com)
Within days of the rollout, several community testers and specialist outlets reproduced a consistent failure profile: during sustained, large sequential writes—commonly reported in community tests at roughly 50 GB or more, especially when the target SSD was already moderately full—some drives would suddenly stop responding, disappear from File Explorer and Device Manager, and present unreadable SMART/controller telemetry. Reboots sometimes restored visibility but did not guarantee any data written during the incident window remained intact. (tomshardware.com, bleepingcomputer.com)
Phison — a major SSD-controller designer — publicly acknowledged it had “recently been made aware of the industry‑wide effects of the ‘KB5063878’ and ‘KB5062660’ updates on Windows 11 that potentially impacted several storage devices” and said it was investigating with partners. Microsoft has confirmed it is investigating reports and working with partners. (wccftech.com, tomshardware.com)

---

What users and testers are seeing​

Core symptoms​

• The target drive becomes unresponsive mid-write and may disappear from Device Manager, Disk Management, and File Explorer. (tomshardware.com)
• SMART and vendor telemetry may stop responding and report unreadable or unavailable attributes. (tomshardware.com)
• File copy, extraction, or installation can hang, I/O errors appear in logs, and files written during the event may be corrupted or incomplete. (bleepingcomputer.com)
• In many cases a reboot brings the device back, but in a minority of cases the drive remains inaccessible or the partition shows as RAW — indicating on-disk metadata or partition-table damage. (tomshardware.com, bleepingcomputer.com)

Trigger profile (what reproduces the bug)​

Independent community tests converge on a narrow reproduction window:

• Sustained, sequential writes of roughly 50 GB or more in a single operation (examples: large game updates, archive extraction, cloning, or mass media copies) were the most consistent triggers. (tomshardware.com, bleepingcomputer.com)
• Drives already >50–60% full appear more vulnerable, likely because effective SLC caching and free-block availability are reduced. (tomshardware.com)
• Splitting the same write into smaller chunks or throttling the write rate sometimes avoided the failure in repeat tests, suggesting the failure depends on sustained pressure to controller/OS buffering stacks.

These observations are based on community reproductions and specialist reporting; they are credible and technically coherent but remain a working hypothesis pending vendor/Microsoft forensic telemetry. Treat these thresholds as investigative signals, not definitive rules. (tomshardware.com, bleepingcomputer.com)

---

Which drives appear in reports (and why lists are unreliable)​

Early community collations and specialist outlets named several models and controller families more often than others, notably drives using Phison controllers (including the PS5012‑E12 lineage and related families), and a handful of designs from other controller vendors. Examples surfaced in testing logs and posts: WD Blue SN5000, Corsair MP600 / MP510, Crucial P3 Plus, SK hynix Platinum P41, ADATA LEGEND 800, XPG SX8200 Pro and others.
Important caveats:

• Not every drive of a named model or controller family fails in every test bench. Firmware revision, NAND configuration, drive capacity, host platform (chipset, BIOS), and current free-space all materially affect reproducibility. (tomshardware.com)
• Community model lists are investigative leads, not vendor-validated recall lists. SSD vendors and controllers are deployed across many branded SKUs with different firmware and BOMs; vendor-level firmware differences can make two identically labeled drives behave differently.

Because of those variables, it is inaccurate to label entire brands as “good” or “bad” on the basis of these early reports; the correct conclusion is that a narrow workload exposes a fragile interaction between OS buffering and SSD firmware in a subset of drives. (tomshardware.com)

---

Technical theory: what might be happening (current community hypothesis)​

Several independent testers and engineers have converged on a plausible host/controller interaction model. The following is a synthesis of community analysis and vendor statements — not a confirmed root cause.

• Windows update KB5063878 likely altered some host-side buffering or write-back behavior in the storage stack (such changes are plausible in quality/security rollups). (support.microsoft.com)
• Under sustained sequential write stress, the OS may hold a large amount of buffered data before issuing flush/FUA operations or applying backpressure to the I/O queue. This can let I/O queues grow in ways the SSD’s firmware does not expect. (tomshardware.com)
• When the SSD is already largely filled (reduced spare area), its SLC cache is effectively smaller, and the drive’s FTL (flash translation layer) ramps garbage collection and wear-leveling, greatly increasing write amplification. That raises controller load and latency. (tomshardware.com)
• The combination of heavy host write buffering and increased controller-side work can push the controller into a state where it hangs, resets, or stops responding to NVMe commands. When the controller stops responding, the host may treat the device as removed from the PCIe/storage topology. File-system metadata updates in-flight can be left incomplete, producing RAW volumes or corrupted NTFS/partition tables. (tomshardware.com, bleepingcomputer.com)

This chain explains the empirical symptoms (vanish from OS, unreadable SMART, corruption). However, it does not prove causation — only that the observed behaviors are consistent with a controller-side hang triggered by a specific host workload. Final determination requires collected error traces, controller logs, and coordinated debugging from Microsoft and controller vendors. Phison has indicated it is performing that review. (wccftech.com)

---

Timeline and vendor responses​

• August 12, 2025: Microsoft releases KB5063878 (OS Build 26100.4946). The public KB initially lists no known storage issues. (support.microsoft.com)
• Within days: Community testers reproduce a reproducible failure mode where drives disappear during heavy writes; initial signals originate from users in Japan and hobbyist test benches.
• Mid-August 2025: Phison acknowledges it has been “made aware” of the issue and is investigating controllers that might be affected and working with partners; other vendors begin triage and some publish advisories. Microsoft says it is investigating with partners. (wccftech.com, tomshardware.com)
• Microsoft also addressed a separate WSUS/SCCM deployment error (0x80240069) linked to the same package via Known Issue Rollback (KIR) mitigations for enterprise channels. That installation problem was later resolved and Microsoft advised organizations to refresh/sync WSUS. (support.microsoft.com, neowin.net)

This is an active, ongoing investigation; vendor collaboration and firmware updates are the most likely remediation paths. (wccftech.com, tomshardware.com)

---

Practical impact and recovery scenarios​

There are two general outcomes reported by users and testers:

• Milder, more common outcome: Drive vanishes mid-write but recovers after reboot. The device reappears and basic SMART is readable again. Data that was being written at the moment of failure may be corrupted or incomplete, but the drive itself remains usable. (tomshardware.com)
• Severe, less common outcome: Drive does not return cleanly and partitions/metadata appear corrupted (RAW). In these cases SMART and controller telemetry may be unreadable, and the OS or BIOS might briefly not enumerate the device. Testers have sometimes recovered drives by rewriting partition tables (TestDisk) or performing full media erase / zero-fill from Linux tools, but that destroys user data. Some drives required vendor-level reflash or RMA. (bleepingcomputer.com, tomshardware.com)

Uninstalling the Windows update after on-disk damage has occurred does not necessarily restore corrupted metadata or files; the damage is often on-media and persists across host-side uninstall. That makes pre-emptive backups the single most important mitigation. (tomshardware.com)

---

Recommended actions for consumers and administrators​

The situation demands pragmatic, risk-based choices for individuals and IT teams. The following recommendations synthesize community reproductions, vendor guidance, and Microsoft’s stance.

Immediate steps (for any user)​

• Back up critical data now. If you have not recently backed up, do this immediately before running heavy write workloads or attempting repairs. Backups are the only reliable defense against media corruption. (tomshardware.com)
• Check your Windows build: Settings > System > About will show your OS Build (KB5063878 corresponds to Build 26100.4946). If you are on that build and have any suspect drives, treat heavy writes with caution.
• Avoid sustained, large sequential writes (game updates, large archive extraction, cloning, mass media copies) until vendors publish firm guidance or firmware updates. Splitting transfers into smaller chunks or throttling copy operations may reduce risk. (tomshardware.com)

If your drive disappears mid-write​

• Stop doing new writes to that drive immediately. Continued writes can worsen metadata damage. (bleepingcomputer.com)
• Reboot and check whether the drive reappears. If it does, run vendor tools to read SMART attributes and capture logs for vendor support. (tomshardware.com)
• If the device remains inaccessible, do not reformat. Image the raw device (dd or vendor imaging tools) if possible, capture vendor logs, and contact the SSD vendor for RMA/diagnostics. Attempting blanket reformatting risks permanent data loss. (bleepingcomputer.com)

For IT administrators and fleet operators​

• Stage KB deployments in representative test rings that include the exact storage hardware used by your fleet, especially if using third-party SSDs with Phison controllers. (tomshardware.com)
• Hold large, automated write jobs (imaging, backups, content updates) on recently patched machines until vendor advisories or tested firmware are available. (tomshardware.com)
• Monitor Microsoft’s release health dashboard and vendor advisories and prepare to deploy SSD firmware updates via validated channels. Microsoft’s Known Issue Rollback (KIR) and traditional servicing controls may be applied for enterprise scenarios; follow Microsoft’s guidance for WSUS/SCCM if you use those systems. (support.microsoft.com, neowin.net)

---

What remediation will likely look like​

Historically, incidents of this type have resolved through a combination of:

• Controller vendor firmware updates that fix internal state-machine or DMA-handling edge cases. Controller vendors typically coordinate firmware with drive-brand partners before public distribution. Phison’s public statement indicates that this is their primary response path. (wccftech.com)
• Microsoft OS-side mitigations where necessary (patches, driver updates, or precisely scoped release rollbacks) if telemetry shows the host is contributing to unsafe behavior. (support.microsoft.com)
• Vendor advisories for end users (workarounds such as avoiding heavy sequential writes, or instructions for firmware updates). These will likely be distributed via drive-brand support pages and update utilities. (tomshardware.com)

Expect the fix cycle to follow the established co-engineered path: vendor forensic work, a targeted firmware release, and then staged deployment to consumers and enterprises. Because firmware updates carry their own risk profile, vendors will test extensively before pushing mass updates. (wccftech.com, tomshardware.com)

---

Strengths and limitations of the evidence so far​

Strengths​

• Multiple independent reproductions by community testers and specialist hardware outlets produced a consistent symptom set and workload trigger, which elevates the reports above isolated anecdotes. (tomshardware.com, bleepingcomputer.com)
• A major controller supplier (Phison) has publicly acknowledged the investigation and committed to working with partners, which indicates vendors take the reports seriously and are cooperating on root cause analysis. (wccftech.com)

Limitations and open questions​

• Microsoft’s official KB initially reported no known issues for KB5063878; while Microsoft now says it is investigating with partners, there is not yet a vendor-validated, public root-cause statement. That leaves room for competing hypotheses (controller firmware bug, host stack regression, BIOS/PCIe firmware interactions). (support.microsoft.com, tomshardware.com)
• Community model lists are heterogeneous and often conflate different firmware SKUs, capacities, and host configurations; this makes any definitive public “affected drive” list unreliable until vendors publish validated inventories.
• Some commentators caution that spontaneous drive failures do happen and correlation is not proof of causation; however, the reproducible workload pattern and clustering around certain controllers strengthen the suspicion of an update-triggered interaction rather than coincidence. Until forensic traces from controllers and OS logs are published, full confidence is impossible. (pcgamer.com, techradar.com)

---

How to monitor the situation (trusted signals to watch)​

• Microsoft’s official KB/support and Windows release health dashboard for any Known Issue entries or mitigations to KB5063878. (support.microsoft.com)
• Official advisories and firmware downloads from SSD vendors and their brand partners (Crucial, Western Digital, Corsair, ADATA, SK hynix, etc.). (tomshardware.com)
• Phison’s partner advisories and firmware bulletins — Phison has publicly acknowledged the issue and said it will coordinate with partners. (wccftech.com)
• Reputable hardware outlets and specialist labs that reproduce tests (Tom’s Hardware, BleepingComputer, TechRadar, and others) for validated, repeatable test logs rather than forum hearsay. (tomshardware.com, bleepingcomputer.com, techradar.com)

---

Long-term lessons for Windows users and IT teams​

This incident highlights three recurring truths about modern PC storage:

• Modern storage is a co‑engineered system: OS, driver, firmware, BIOS/UEFI, and workload all matter. Small host-side timing or buffer changes can expose latent firmware bugs that stayed dormant until a particular stress pattern surfaced them. (tomshardware.com)
• Robust backup discipline is the least glamorous but most effective mitigation. When low-level storage metadata is at risk, backups (and images) are the only reliable recovery path. (tomshardware.com)
• Staged rollouts and representative test rings are essential for organizations. Fleet testing must include representative storage hardware and write workloads to catch these rare but high-impact regressions before broad deployment. (tomshardware.com)

---

Conclusion​

The August 12, 2025 Windows 11 cumulative (KB5063878, OS Build 26100.4946) has been linked by multiple independent test benches and specialist outlets to a reproducible storage‑device regression that can make certain SSDs vanish during sustained heavy writes and risk data corruption. Phison has acknowledged it is investigating and Microsoft says it is working with partners. The evidence is strong enough to warrant immediate, conservative actions — foremost, backing up important data and avoiding sustained large writes on systems that received the update until vendors release validated firmware or guidance. (support.microsoft.com, tomshardware.com, wccftech.com)
This remains an unfolding, technical investigation that will ultimately require coordinated telemetry and firmware patches to resolve the interplay between Windows’ storage stack and SSD controller firmware. Until vendors publish firm fixes and validated guidance, prioritize backups, stage updates, and treat any mid-write disappearance of a storage device as a potential data‑loss event requiring careful forensic handling. (tomshardware.com, bleepingcomputer.com)

---

Source: windowslatest.com Microsoft is investigating Windows 11 KB5063878 SSD data corruption/failure issue

 

[ChatGPT]

Microsoft and several SSD vendors are investigating reports that a recent Windows 11 cumulative update can cause some solid-state drives to stop responding or “vanish” from the operating system during sustained, large file writes — a failure mode that can leave files corrupted or, in a minority of cases, drives inaccessible even after reboot. rview
The issue has been tied to Windows 11 cumulative packages distributed in mid‑August 2025 (commonly tracked as KB5063878, with related reports also mentioning KB5062660) and was first flagged by community testers who reproduced a consistent failure profile under heavy sequential write workloads. Early vendor acknowlontroller maker raised the severity of the reports and pushed Microsoft to confirm an active investigation.
These events are not merely cosmetic: comons and specialist outlets report that the drive can disappear from File Explorer, Device Manager and Disk Management during large transfers; vendor utilities may lose SMART and telemetry access; and files being written at the time of the failure are at risk of corruption. Reboots often restore visibility but do not guarantee data integrity.

---

What the reports show: symptoms and trigger profile​

istent across independent reports)​

• SSD becomes unresponsive mid‑write and disappears from the OS topology (File Explorer, Device Manager, Disk Management).
• Vendor tools show unreadable or absent SMART/controller telemetry after the eventhang or fail; files written during the incident are often truncated or corrupted.
• Icases a reboot returns the drive; in a smaller subset the drive remains inaccessible and may require vion or reformatting.

Typical trigger profile​

Community reproductions converge on a narrow set of conditions:

• Sustained sequential writes — examples include larive extraction, disk cloning, or bulk media transfers. The failure commonly appears after tens of gigabytes are written in a single continuous operation.
• The most frequently reported threshold falls around ~50 GB of continuous writes in a single operation. This is a community‑observed pattern, not an absolute rule, independent test beds.
• Drives that are already substantially full (community reports often cite >50–60% used capacity) appear more vulnerable, likely because SLC caching and free-block availability are reducions.

These trigger characteristics suggest the regression is workload-sensitive — it manifests on a particular sustained I/O profile that stresses controller caching and host‑to‑device command timing rather than appursty desktop use.

---

Who’s involved: vendor and platform responses​

• Phison, a widely used SSD controller supplier, publicly acknowledged it had been “recently made aware of the industry‑wide effects” of the updates and said it was investigating potentially impacted controllers and coordinating with partners. That statement elevated the incident from isolated forum posts to an industry incident requiring cross‑vendor forensic work.
• Microsoft confirmed it is aware of reports and is investigating with partners. At the time early community reports went public, Microsoft’s public KB page did not list a storage regression; the company subsequently engaged with gained traction.
• Multiple specialist outlets and independent testers reproduced the failure profile and compiled device lists and reproduction steps. Those community lists were useful for triage but are explicitly provisional until vendors publish validated inventories es.

---

Technical analysis: plausible mechanisms​

While the forensic root cause remains under active investigation, the technical signals point to a host‑to‑controller interaction exposed under a narrow stress profile rather than a straightforward file‑system bug. Key techniclude:

• Controller firmware edge cases: NVMe controllers have complex firmware that manages SLC caching, garbage collection, wear leveling, and metadata updates. A host change in command timing or resource allocation can expose a latent firmware race or unhandled edge condition that causes the controller to lock up or fail to respond to host commands. Community reproducibility under sustained writes aligns with a firmware‑level lockup hypothesis.
• Host Memory Buffer (HMB) and DRAM‑less designs: Some DRAM‑less SSDs rely on HMB allocations from the host. Changes in how Windows allocates or times HMB resources can destabilize such drives under heavy loads. Prior Windows 11 24H2 rollout issues demonstrated how HMB allocation changes can weaknesses; this incident could be a related interaction but must be validated by telemetry.
• Sustained DMA and queue pressure: Long sequential writes generate prolonged DMA traffic and saturate NVMe queues, which can stress controller state machines and host driver buffer handling. If firmware does not correctly manage state transitions under sustained queue pressure, the controller may become unresponsreset or a firmware patch restores proper recovery paths.
• Platform/BIOS interplay: Motherboard BIOS, PCIe root complex drivers, and chipset behavior can influence how an NVMe controller is enumerated and reset. Some community reports note BIOS/UEFI or platform differences that affect reproducibility, suggesting the problem may be multi‑component rather than purely vendor or Microsoft‑side.plausible technical pathways grounded in the observed behavior and historical precedents; the definitive root cause requires coordinated telemetry from Microsoft and SSD vendors (controller logs, host kernel traces, and firmware dumps).

---

A clear, practical set of immediate actions​

The guidance below consolidates what independent tess and platform management best practices are recommending while a root cause is determined.

For consumers and single‑system users​

• Back up critical data now. Copy irreplaceable files to a separate physical drive or cloud storage before performing any large writes on a system that has received the August cumulative. Backups are the only guaranteed defense against potential data loss.
• Avoid sustained large sequential writes to SSDs on patched systems until vendors publish mitigation or firmware updates. This includes large downloads, game installs, archive extractions, imaging, or disk cloning. Community reproductions commonly used large game downloads as triggers.
• Check whether KB5063878 (or the implicated build) is installed. Run winver or gs Update → Update history to confirm the presence of the update. If you need to remove the LCU component, note that this package may include a combined SSU + LCU that requires DISM /Remove‑Package rather than wusa /uninstall for the LCU portion. Test guidance from Microsoft should be followed fodures.
• Do not immediately reformat or run intrusive writes if a drive disappears mid‑transfer. Power down, capture event timestamps and logs (Event Viewer), and, if the data is critical, image the device before further attempts at recovery. Imaging preserves evidence and improves the odds of successful vendor recovery.

For IT administrators and fleet managers​

• Pause broad deployment of the patch. Use WSUS, SCCrosoft’s Known Issue Rollback mechanisms to withhold KB5063878 from production fleets until you have tested representative storage hardware under sustained‑write workloads.
• Inventory and triage potentially affected storage. Create a prioritized inventory of systems with at‑risk SSD models and controller families;ress tests and block large sequential write operations on mission‑critical endpoints during the investigation.
• Collect and escalate forensic telemetry. If a failure occurs on a managed device, collect Event Viewer logs, vendor diagnostics, SMART dumps, firmware versions, and a disk image consolidated telemetry to the SSD vendor and Microsoft to accelerate root‑cause analysis.

---

Recovery guidance if a drive disappears mid‑transfer​

If a drive disappears during a transfer, follow a conservative workflow to maximize recovery chances:

• Power down the machine irther writes and potential state changes. Document timestamps and the operation that was in progress.
• Boot from external media if you need to access the rest of the storage stack. Do not perform destructive writes or automated repair tools until you have imaged the drive.
• Create a forensic rive using a hardware bridge or a write‑blocker if the data is important. This preserves the state for vendor analysis or professional recovery.
• Contact the SSD vendor’s support channel with logs and the image. Vendor firmware tools and diagnostics may be able to recover a controller that is stuck but inaccessi## Why rapid community reproducibility matters — and why it isn’t proof of a universal failure

The rapid, multi‑site reproducibility of the failure under similar I/O profiles he claim that a specific host change interacts poorly with certain controller firmware paths. Several independent labs and testers reproduced the symptom set, which is why vendors and Microsever, community‑collected device lists and reproduction notes are triage leads, not authoritative blacklists. Whether a drive fails depends on the exact combination of:

• controller silision,
• branded drive factory configuration and overprovisioning,
• host BIOS/UEFI and chipset drivers, and
• the specific workload and current drive utilization.

As a result, a model appearing frequently in community reports may be over‑represented for a variety of sampling reasons; vendors must validate lists against production telemetry before issuing recalls or mandatory firmware updates.

---

Vendor and platform remediation pathways​

Realistic remediation typically follows these paths:

• Controller firmware updates: If the root cause is a firmware bug triggered by altered host behavior, SSD vendors will release firmware revisions to harden the controller’s state machine, improve recovery logic, or change cache/metadata handling under sustained writes. Firmware fixes are the most direct and durable cure but require careful testing and distribution.
• Microsoft OS-side patch or driver change: If the issue arises from a change in host timing, resource allocation (for example, HMB behaviores, Microsoft could issue a targeted patch to revert the offending change or adjust host behavior to maintain compatibility while vendors provide firmware updates. Coordinated platform fixes are more complex but possible.
• Known Issue Rollback / Update management controls: Microsoft can use rollout controls to throttle or block the problematic update while a fix is developed and validated; organizations should use centralized update management to apply these mitigatio path carries tradeoffs: firmware updates risk shipping a new firmware that must be validated across many SKUs; OS patches must be carefully tested to avoid regression; and rollout blocks delay security fixes. The coordinated vendor‑platform approach minimizes risk by aligning these steps.

---

Risks, tradeoffs and long‑term lessons​

Notable strengths of current response​

• VendPhison) and Microsoft engagement** moved the issue from forum chatter to a coordinated investigation rapidly, which is the correct first step for platform‑level incidents.
• Independent community reproducibility focused the investigation on a specific ng vendors actionable test vectors to validate fixes.

Potential risks and downsides​

• Data-loss risk for affected users is real and immediate. Files written during the failure window are at risk of corruption; some reports describe drives that require reformatting or professional recovery.
• Firmware update distribution complexity. Many consumer drives use vendor utilities or require vendor‑specific update channels; coordinating a broad, validated firmware rollout is time‑consuming and error‑prone.
• Operational tradeoffs for administrators. Pausing security updates while regressions introduces security exposure; organizations must triage which systems can safely delay updates and which must stay protected.

System‑design lessforces a structural truth of modern PCs: storage reliability depends on a finely balanced choreography between OS behavior, host drivers, chipset firmware, and SSD controller firmware. Even small host‑side changes can expose latentragility argues for disciplined update staging, robust backup practices, and vendor‑grade regression tests that include sustained large‑write workloads in preproduction validation rings.​

---

Practical checklist (cotical data immediately.​

• Avoid large sustained writes (>~50 GB in one operation) on systems that received the August cumulative.
• Check whether KB5063878 (or the implicated build) is installed and pause further rollout until vendor gu
• If a drive disappears: power down, document the event, image the drive before further writes, and contact vendor support.
• For fleets: inventory potentially affected devices, stage updates, collect telemetry, and use update management to control exposure.

---

Conclusion​

The emerging SSD disappearances tied to Windows 11 cumulative updates are a high‑impact, workload‑sensitive storage regression that must be treated seriously. Independent reproductions and vendor acknowledgments makhan isolated user error; it is an interaction between host software changes anbehavior that can produce real data loss. The right operational posture is conservative: back up, avoid heavy patched systems, stage updates, and follow vendor and Microsoft advisories for firmware or OS fixes. Coordinated telemetry from ae necessary to pin down the root cause and deliver durable remediation; until then, prioritize data protection and controlled u

---

Source: xda-developers.com Microsoft is investigating a nasty SSD bug that might cause your drive to become undiscoverable