Windows 11 KB5063878 Breaks Some SSDs Under Heavy Writes (Phison PS5012-E12)

Phison has publicly acknowledged that two recent Windows 11 security updates — KB5063878 and KB5062660 — are associated with a cluster of SSD failures that make drives vanish during large, sustained write operations, and the admission has sparked urgent questions about update testing, firmware resilience, and how storage vendors handle rapid-fire remediation. (tomshardware.com) (support.microsoft.com)

Background​

Windows Update delivered a combined Servicing Stack Update and Latest Cumulative Update on August 12, 2025 (KB5063878, OS Build 26100.4946). Microsoft’s official release notes list the security and quality fixes included in the package and — at the time community reports emerged — stated the company was “not currently aware of any issues with this update.” (support.microsoft.com)
Within days, independent testers and multiple enthusiast outlets documented a reproducible failure mode: during large sequential writes (commonly reported around ~50 GB or more), some NVMe SSDs stop responding, disappear from Device Manager and Disk Management, and return unreadable SMART/controller telemetry; a minority of users reported file corruption or permanent inaccessibility after rebooting. Community collations repeatedly named certain Phison-controller-based drives — notably those using the PS5012-E12 family — among the affected models. Those community reports and hands‑on reproductions were shared widely across enthusiast forums and specialist sites. (igorslab.de)
This incident echoes an earlier class of Windows 11 24H2 storage problems from late 2024 in which Host Memory Buffer (HMB) allocation changes and OS-side behavior exposed firmware bugs in DRAM‑less NVMe designs. That precedent explains why firmware and OS interactions are now central to investigations.

---

What happened: symptoms, trigger profile, and affected devices​

The failure fingerprint​

• Drives disappear from File Explorer, Device Manager, and Disk Management mid-write.
• SMART and controller telemetry become unreadable or return errors to vendor utilities.
• Reboot sometimes restores the drive temporarily; repeated heavy writes often reproduce the fault.
• A subset of users report corrupted, missing, or inaccessible files after the event.

These behaviors are consistent with a controller-level hang or lock-up where the SSD stops responding to NVMe admin commands and the host OS treats the device as removed from the PCIe/storage topology. Community test reproductions repeatedly identify sustained sequential writes as the typical trigger. (notebookcheck.net)

Typical trigger profile​

Independent reproductions converge on a workload profile common in real life:

• Continuous sequential writes on the order of ~50 GB or more (game installs, large archive extractions, cloning).
• Elevated controller utilization (community reports note spikes above ~60%).
• Triggers appear more likely when the target drive is already substantially utilized (for example, >50–60% used space).

This workload stresses multiple layers — the OS page cache, kernel I/O scheduling, DMA handoffs, and the SSD controller’s internal metadata pathways — making it easy for timing or state-machine bugs to surface.

Devices and controllers named in reports​

Community-compiled lists and hands-on tests repeatedly mention the following as among the models that have shown trouble (lists are evolving and not vendor-confirmed):

• Corsair Force MP600 (Phison E16/E18-era variants)
• Drives using Phison PS5012‑E12 family controllers
• Kioxia Exceria Plus G4
• SanDisk Extreme Pro M.2 NVMe 3D
• Various DRAM‑less and Phison-based SKUs across brands

It is important to note that not every drive using a named controller is affected, and some non‑Phison drives have also shown similar symptoms in isolated tests. Treat community lists as investigative leads rather than definitive recall inventories. (guru3d.com)

---

What vendors have said (and what they have not)​

Phison issued a concise statement acknowledging it had been “recently made aware of the industry‑wide effects of the ‘KB5063878’ and ‘KB5062660’ updates on Windows 11 that potentially impacted several storage devices,” and that the company was “working with partners” to identify affected controllers while committing to product integrity. The statement stopped short of assigning a definitive root cause or naming specific controller revisions or firmware changes. (tomshardware.com)
Microsoft’s public KB page for KB5063878 — the canonical package listing — continued to show the standard release notes and the language that the company was “not currently aware of any issues with this update” at the time community testing surfaced the storage regressions. That phrasing is procedurally standard but has become a flashpoint: community reproductions pointed to a reproducible failure mode, while Microsoft’s release health page and KB entries had not immediately recorded a related known issue. (support.microsoft.com)
Other SSD vendors and platform OEMs have been slower to publish global advisories; where they have acted, remediation has historically followed one of two patterns:

• Vendor firmware updates that correct controller-level logic exposed by the host behavior.
• Microsoft mitigations (known-issue rollbacks or feature blocks) while firmware patches are distributed.

Community guidance so far encourages users to check OEM utility tools (Corsair iCUE, SanDisk Dashboard, Kioxia/CST utilities, etc.) for firmware notices and to avoid heavy writes until the vendor/Microsoft guidance arrives.

---

Why a Windows update can break SSDs: the technical anatomy​

Modern NVMe SSDs are embedded systems: controller firmware, optional on‑board DRAM, NAND channels, LDPC/FTL logic, and the host OS driver form a tightly coupled runtime system. Two concepts explain why an OS change can surface a controller bug:

• Host Memory Buffer (HMB): DRAM‑less drives borrow host RAM for mapping tables and caching. Changes in how the OS allocates or manages HMB can change timing and memory patterns that the controller previously never encountered in the field.
• Sustained sequential writes: These stress the controller’s internal metadata updates, garbage-collection triggers, thermal throttling, request queuing, and error-handling paths. An unexpected host-issued sequence or altered timing can push the controller into an unhandled state.

When firmware contains a latent race condition or state-machine assumption that the host previously did not exercise, the controller can hang, stop responding to admin commands (making the drive “disappear”), and present unreadable SMART or vendor telemetry until a firmware-level reset or low-level reinitialization occurs. The symptom set observed here — disappearance mid-write and unreadable controller telemetry — is consistent with a controller lock-up scenario, though an OS-level timing/regression remains a plausible or co-causal mechanism. (igorslab.de)

---

Verifying the claims: what is confirmed and what remains unproven​

What can be verified now:

• Microsoft released KB5063878 on August 12, 2025 as the cumulative LCU + SSU for Windows 11 24H2 (OS Build 26100.4946). The official KB notes do not initially list a storage-device known issue. (support.microsoft.com)
• Multiple independent community reproductions show NVMe SSDs becoming inaccessible under sustained, large writes after the update, often around the ~50 GB threshold in test cases. These reproductions appear across specialist outlets and forum threads. (notebookcheck.net)
• Phison has publicly said it is investigating and working with partners; the vendor did not assert it has a final root-cause analysis. (tomshardware.com)

What is not proven and requires caution:

• A definitive root-cause attribution that pins the fault solely on Phison PS5012‑E12 controllers, or on a specific instruction sequence internal to KB5063878, has not been published by Microsoft or a major vendor. Community evidence points to Phison families being over‑represented in early repros, but the dataset is limited and heterogeneous. Treat Phison-specific claims as plausible but still under investigation until vendors or Microsoft publish telemetry-backed confirmations.

The responsible conclusion for journalists and admins is that a reproducible storage regression exists under a defined workload profile, but the precise locus of the defect (host vs. firmware vs. combined) remains unproven publicly and needs coordinated telemetry and controlled lab confirmation from the parties involved.

---

Immediate practical guidance for users and administrators​

These steps are conservative, actionable, and prioritize data protection.

• Back up critical data immediately to an independent device or cloud. Backups are the only reliable protection against mid‑write corruption or device loss.
• Avoid sustained, large sequential writes (> ~50 GB) on Windows 11 systems patched with KB5063878 or KB5062660 until your drives and platform are validated.
• If KB5063878 is not yet installed and your workflow involves heavy writes, stage the update in a test ring that includes representative storage hardware; withhold broad deployment until vendors and Microsoft confirm fixes.
• Check vendor update utilities (Corsair iCUE, SanDisk Dashboard, Kioxia Storage Utility) for firmware advisories and apply only vendor‑approved firmware after completing backups.
• For fleets using WSUS/SCCM, use update-management controls to temporarily block or stage KB5063878 until remediation is validated — Microsoft has previously used Known Issue Rollbacks for similar distribution issues.
• If a drive becomes inaccessible, power down and image the device (forensic image) before performing writes or reformatting; capture Event Viewer logs, NVMe trace logs, and vendor telemetry to help diagnostics and RMA processes.

These steps reflect community best practice and the conservative posture recommended by storage specialists. (notebookcheck.net)

---

Recovery and forensics: how to handle a failed SSD safely​

• If disappearance occurs mid‑write, avoid reusing the drive or running destructive diagnostics. Power the machine down and document the steps.
• Create a forensic disk image (dd, FTK Imager, or vendor imaging tool) to preserve evidence before attempting repairs.
• Collect logs: Event Viewer errors referring to NVMe, storvsc/stornvme, or controller errors; vendor diagnostic outputs; and Windows Reliability Monitor entries.
• Submit the image and logs to the SSD vendor for engineering analysis; escalate RMA requests with copies of logs and step-by-step repro cases if possible.

Imaging preserves any recoverable sectors and helps engineering teams determine whether corruption is at the file-system level or deeper in the controller metadata/FTL. The community strongly advises imaging before reformatting because reformatting can destroy forensic traces that might be critical for vendor fixes or warranty support.

---

Why this incident is a broader systemic concern​

• Update safety vs. security: Security rollups are essential, but when a security update triggers regressions that risk data integrity, vendors must balance rapid patching with more conservative compatibility gating for known fragile subsystems like storage.
• Complexity of modern storage: NVMe SSDs integrate hardware and firmware complexity that depends on specific host behaviors. Subtle changes in the OS kernel, driver behavior, or memory allocation paths can exercise latent firmware bugs.
• Vendor coordination and transparency: Quick, authoritative vendor advisories and targeted firmware updates (or Microsoft mitigations) are the fastest path to restoring confidence. Vague statements acknowledging investigation do not materially reduce end‑user risk.
• Enterprise risk: Organizations that auto-deploy cumulative updates without representative hardware validation expose fleets to avoidable data integrity risks; the ability to block or stage updates is critical.

---

Critical analysis of Phison’s response and Microsoft’s handling​

Phison’s statement is factual but measured: acknowledging the issue, pledging partner coordination, and committing to updates. That posture is typical and appropriate for a component vendor whose remediation path often runs through board/drive partners. However, the statement lacks timelines, affected firmware identifiers, or concrete mitigation guidance for end users — information that would materially reduce the time-to-resolution for IT teams and power users. (tomshardware.com)
Microsoft’s initial KB language that it is “not currently aware of any issues” is standard but increasingly mismatches real‑world rapid community testing. The KB entry’s lack of an immediate known‑issue entry for a reproducible storage regression undermines visibility and delays enterprise risk mitigation steps such as Known Issue Rollbacks and staged distributions. Quick insertion of an official “known issue” with mitigation guidance (block list, recommended firmware versions, or staging advice) would be the responsible next step. (support.microsoft.com)
Both firms face coordination challenges: vendors must identify exact firmware revisions and partner SKUs affected; Microsoft must decide whether to apply distribution blocks or supply per‑device mitigations. Transparency about which firmware revisions are confirmed to be safe — and which are not — would reduce unnecessary panic and help administrators plan. At present, the public signals are fragmented: strong community evidence of reproducible failure; vendor acknowledgment of investigation; and Microsoft’s KB still listing no known issues.

---

The longer-term lessons for update engineering and storage vendors​

• Expand pre-release testing to cover sustained sequential write workloads that mirror real-world large file transfers, game installs, and cloning scenarios. Update pipelines should include long-duration I/O stress tests on representative DRAM‑less and Phison-based controllers.
• Improve telemetry and feedback loops that allow Microsoft and controller vendors to correlate OS logs with device telemetry quickly — faster correlation reduces mean time to identification and remediation.
• Make firmware rollback options tractable for end users or provide vendor update utilities that support safe rollbacks when a firmware regression is detected.
• For critical security updates, consider a staged, hardware-aware rollout that treats storage controllers and low-level driver interactions as first-class compatibility gates.

---

Conclusion​

The KB5063878 / KB5062660 episode is another reminder that modern update ecosystems are not just software problems; they are socio-technical systems that link OS maintainers, controller vendors, drive integrators, OEMs, and the user community. Community testbeds and enthusiast reproducibility have again exposed a tangible risk: reproducible SSD disappearances under sustained large writes after a Windows 11 security update. Phison’s public acknowledgement that it is investigating and coordinating with partners is a necessary step, but it does not resolve the immediate user risk: data loss is real for affected systems.
The practical, defensible actions today are clear: back up immediately, avoid heavy writes on patched systems until vendors publish mitigations, and image any failed drive before attempts at repair. Administrators should stage KB5063878 widely and rely on hardware‑representative tests before broad deployment. The technical community and vendors must now converge on a transparent, telemetry-backed root cause and publish concrete firmware or OS mitigations — because the stakes are not limited to performance or crashes, but to the integrity of user data itself. (notebookcheck.net)

---

Source: Fudzilla.com Phison blames Windows 11 update for SSD meltdowns