A growing number of Windows 11 users are reporting that their SSDs vanish mid-transfer after installing the August 2025 cumulative update KB5063878, with Phison—one of the largest SSD controller makers—confirming it is investigating the failures. The bug strikes during sustained write operations of around 50GB or more, especially when drives are more than 60% full, causing SSDs to drop offline, halt file transfers, and in some cases corrupt data permanently. While Microsoft has acknowledged the reports and is working with storage partners, independent testers have already reproduced the issue across multiple drive brands and controller families, elevating this from rumor to a credible threat for power users and IT administrators.
The trigger: 50GB writes on a near-full drive
The pattern first emerged in community forums and on X (formerly Twitter) within days of KB5063878’s release. User Nekorusukii (@Necoru_cat) documented repeated failures while updating Cyberpunk 2077: the target SSD disappeared from File Explorer, Device Manager, and Disk Management, and SMART telemetry became unreadable. A reboot sometimes restored visibility, but the files written during the incident were truncated or corrupted. Subsequent testing by the same user and others zeroed in on a reproducible trigger: a continuous write load exceeding approximately 50GB, with the destination drive already using over 60% of its capacity.
Those thresholds are not vendor-certified limits but practical heuristics drawn from dozens of community test cases. In a controlled experiment, Nekorusukii tested 21 different SSDs by copying a large game library, compressing it, and then extracting the archive onto each drive. Twelve of the drives became inaccessible during the test; one—a Western Digital SA510 2TB—could not be recovered even after a system reboot, requiring vendor intervention or reformat. The other 11 reappeared after a cold boot, but any data written during the failure window was lost.
Japanese tech outlet NichePCGamer corroborated the findings, identifying at least eight additional users on social media reporting identical symptoms. One user with a SanDisk Extreme PRO M.2 NVMe 3D SSD saw the drive vanish after installing a 50GB Honkai: Star Rail patch. Deleting the earlier preview update KB5062660 (released in July 2025) eliminated the problem, strongly implicating the update chain in the regression.
What users are seeing: the symptom profile
The failure follows a consistent sequence:
- A large, continuous write operation—installing a game, copying tens of gigabytes of media, or extracting a large archive—starts normally.
- After a certain amount of data (commonly around 50GB, but varying by drive), the transfer stalls or throws an error.
- The destination SSD becomes completely unresponsive and disappears from the operating system: it vanishes from File Explorer, Device Manager, and Disk Management.
- Attempts to query the drive’s SMART data or vendor telemetry return errors or empty results.
- Any files written during the incident are truncated, corrupted, or missing entirely. In some cases the partition table may appear to revert to RAW format.
- A system restart often brings the drive back online, but it does not restore data integrity. A minority of drives require vendor utilities or professional data recovery to become accessible again.
These symptoms point to a low-level failure at the controller or host–bridge interface, not a simple filesystem error. The fact that SMART data becomes unreadable suggests the SSD’s controller is entering a fault state that prevents even basic diagnostic communication.
Which drives and controllers are implicated?
Community collations and hands‑on testing have flagged a range of consumer NVMe SSDs, with a disproportionate number built around Phison controllers. Models that appeared in multiple independent reports include:
- Drives with Phison E18, E21, E27 and other Phison families—many of them DRAM-less designs
- Corsair Force MP600 series
- KIOXIA EXCERIA PLUS G4 and other KIOXIA-branded NVMe drives
- SanDisk Extreme PRO M.2 NVMe 3D SSD
- SSDs using InnoGrit controllers (e.g., IG5236, IG5220)
- Some Maxio-based drives and other SKUs from lesser-known vendors
Crucially, the issue is not universal. Several test benches attempted to reproduce the symptoms and obtained mixed results: a SanDisk SSD PLUS 240GB DRAM-less model, for example, showed no failures even when filled above 60% and subjected to a 62GB continuous write. Firmware revision, motherboard BIOS, PCIe link training, and the specific NAND configuration all appear to influence whether a drive triggers the bug. Community-supplied model lists are therefore starting points for risk assessment—not definitive exclusion lists—and should always be cross-checked with vendor advisories.
The technical picture: what might be happening under the hood
No single root cause has been published by Microsoft or any SSD vendor, but the observable fingerprint points to a problem at or below the SSD controller level, likely triggered by changes in host OS behaviour. Independent analysts and vendor statements suggest several working hypotheses:
- Host‑side buffer or memory handling changes: A buffer memory leak in the OS’s I/O stack, or a subtle alteration to host command timing, could expose firmware edge cases. DRAM-less controllers that rely on Host Memory Buffer (HMB) are particularly sensitive to such changes.
- Flash Translation Layer firmware bug: Sustained sequential writes exercise SLC caching, metadata updates, and garbage collection, generating long-lived controller states. A bug in the FTL’s write path might only surface under sustained load.
- NVMe/driver stack interaction: KB5063878 includes generic quality fixes for storNVMe.sys and related filter drivers. A change in I/O request packet (IRP) ordering, flush semantics, or PCIe command timeouts could, in rare circumstances, trigger a controller-level fault.
- Power management and thermal behaviour: Large writes generate heat and can push controllers into different thermal throttling states. If the update modified idle or power-state transitions, that could alter timing and expose latent firmware bugs.
Phison’s public statement acknowledged that the updates “potentially impacted several storage devices” and that the affected controllers are under review. This industry-level admission reinforces the view that the regression is a cross-stack interoperability problem, not a hardware defect confined to a single model.
Reproducibility and conflicting test results
The community-led investigation moved fast, but it also produced conflicting data. While Nekorusukii’s 21‑drive test showed failures on 12 units, other independent outlets that attempted identical scenarios on different hardware configurations could not reproduce the fault. This inconsistency is not surprising given the number of variables—drive firmware, system BIOS version, CPU/chipset architecture, and even workload shape (compressed vs. uncompressed data) all play a role.
These mixed results underscore why coordinated vendor and Microsoft investigation is essential. Community reproductions are credible operational signals that justify precautionary measures, but they do not provide the forensic certainty needed for a universal fix. Microsoft’s own internal telemetry, according to early statements, had not yet detected a widespread spike in disk failures, which may reflect the narrow set of triggering conditions or the fact that many affected drives self-recover after a reboot.
How worried should you be?
The risk profile splits sharply along usage patterns:
- Casual users: If your daily workflow consists of web browsing, office documents, and streaming, you are extremely unlikely to trigger the failure. The documented conditions—sustained writes above 50GB on a drive that is already more than half full—do not match typical consumer usage.
- Power users and creatives: Video editors, photographers, game installers, and anyone who regularly handles large datasets should take the reports seriously. These workflows align closely with the trigger profile and carry a meaningful risk of silent data corruption.
- IT administrators and organisations: Fleets with diverse storage SKUs should treat KB5063878 as a staging risk. Even if only a fraction of drives are susceptible, the potential for data loss during common bulk transfer operations (system imaging, software deployment, large data migrations) warrants a controlled rollout with representative validation.
Protect yourself now: practical mitigation steps
Until Microsoft and SSD vendors release coordinated remediation, a conservative posture is the safest course:
- Back up critical data immediately. Copy important files to a separate physical drive or cloud storage before performing any large transfers. Backups are the only reliable insurance against mid-write corruption.
- Avoid sustained single transfers above ~50GB on drives that are more than 50–60% full. If a large move is unavoidable, break it into smaller batches or use an external drive that is not known to be affected.
- Check for SSD firmware updates. Visit your SSD vendor’s support portal and apply any available firmware, but only after confirming that a full backup has been taken. Several controller makers historically issue firmware patches to resolve interoperability issues with Windows updates.
- Pause non‑critical updates in managed environments. Use Windows Update for Business, Group Policy, or endpoint management tools to defer KB5063878 on endpoints containing irreplaceable data until your organisation validates the combination of hardware, firmware, and operating system.
- If a drive disappears during a transfer: stop all disk activity immediately. Power down the system, perform a cold boot after 30 seconds, and check Device Manager and Disk Management. Do not format or initialise the drive; instead, consider sector-by-sector imaging to preserve any recoverable data.
- Report incidents through official channels. Use the Windows Feedback Hub and your SSD vendor’s support system to provide detailed logs: drive model, controller and firmware revision, Windows build, and a step‑by‑step description of what happened. This data accelerates root‑cause analysis.
What Microsoft and vendors have said
As of mid‑August 2025, the official line from the key players is one of active investigation rather than confirmed remediation:
- Microsoft acknowledged awareness of user reports and confirmed it is working with storage partners. The company stated that internal testing and telemetry had not broadly reproduced an increase in disk failure, but it requested additional diagnostic data from affected customers via the Feedback Hub and Microsoft Support.
- Phison issued a formal statement to Tom’s Hardware: “Phison has recently been made aware of the industry-wide effects of the ‘KB5063878’ and ‘KB5062660’ updates on Windows 11 that potentially impacted several storage devices, including some supported by Phison. We understand the disruption this may have caused and promptly engaged industry stakeholders. We are steadfast in our commitment to product integrity … the controllers that may have been affected are under review and we are working with partners.”
- Other SSD makers, including KIOXIA and SanDisk, have not yet released public advisories, but specialist press outlets report that several are actively testing firmware revisions in response to the community alerts.
Notably, at the time of these early reports, the KB5063878 support article did not carry a specific “known issue” flag for SSD failures. Users should monitor the official Windows Release Health dashboard and the KB page for updates as the investigation progresses.
Guidance for IT administrators and power users
Organisations that cannot simply pause updates should adopt a risk‑based deployment strategy:
- Test in a representative ring. Deploy KB5063878 to a sample of endpoints that mirror production hardware—particularly those with a mix of SSD controller families and firmware revisions. Include test scenarios that generate sustained large writes on drives that are at least 60% full.
- Use update deferral policies. If your risk appetite does not allow broad deployment, leverage WSUS, Windows Update for Business, or third‑party patch management tools to delay the update on critical systems until vendor‑validated firmware is available.
- Collect forensic data. On any endpoint that exhibits the fault, capture event logs, dump files, and vendor‑tool outputs before rebooting. Package these with a detailed timeline and share them with both Microsoft Support and the SSD vendor.
- Implement temporary workarounds. Redirect large write workloads—such as system images, log exports, or media renders—to unaffected storage tiers (network shares, external USB drives, or cloud buckets) until the risk is resolved.
- Communicate with users. Brief staff—especially creators, engineers, and data analysts—on the symptoms and advise them to report any unexpected drive disappearance immediately rather than attempting repeated reboots that may exacerbate corruption.
What to watch for next
The resolution path will likely involve a combination of firmware updates and, if necessary, an OS‑side microcode or driver patch. Look for these upcoming signals:
- A vendor‑validated list of affected SSD controller revisions and firmware versions.
- Firmware updates from SSD manufacturers that explicitly cite compatibility with KB5063878 (or the related KB5062660).
- A Microsoft technical advisory clarifying whether the fix will be a pure firmware remediation, an OS/driver rollback, or an update to the cumulative package itself.
- Independent confirmation that a fix addresses the issue across multiple controller families and motherboard chipsets.
If no coordinated advisory is available for your specific SKU, maintain strict backup discipline and avoid stress‑testing storage until you are certain your hardware/firmware combination has been validated. The community‑driven signal is strong enough to justify a cautious posture, even while the official investigation continues.
In the coming weeks, the collaboration between Microsoft, SSD controller vendors, and the power‑user community that first raised the alarm will determine how quickly the industry can roll out a durable fix. For now, the single most important action any user can take is a fresh backup—because in the world of storage regressions, it is the data you can recover, not the drive you can reboot, that matters most.