Windows 11 24H2 KB5063878: NVMe/PHISON Drives Disappear Under Heavy Writes

Microsoft’s August cumulative for Windows 11 24H2 (KB5063878) has been tied to reports that, under specific heavy-write conditions, some NVMe SSDs — particularly Phison-controller models — and a small number of HDDs can become inaccessible and in some cases suffer file corruption, prompting renewed warnings about immediate backups and cautious update deployment.

Background / Overview​

The patch in question was published as part of the August cumulative updates for Windows 11 version 24H2 (OS Build 26100.4946). Independent testers and community researchers documented a reproducible failure mode: during large, sustained write operations (test cases used transfers of roughly 50–100 GB and workloads that push a drive’s controller usage over ~60%), the target drive can disappear from Windows, SMART data becomes temporarily unreadable, and partitions may later present errors or be entirely inaccessible. Affected drives sometimes reappear after a reboot, but the fault can recur reliably when the same workload is repeated — and crucially, users report a high likelihood of file corruption when symptoms occur.
The reports surfaced via a collection of community posts, social-media threads and technical write-ups from independent outlets and testers. Vendor and ecosystem reaction has varied: some SSD controller makers have acknowledged they are investigating potential interactions between recent Windows updates and drive behavior, while Microsoft’s public update documentation for the cumulative release initially did not list a known issue matching these symptoms.
This story is an important reminder that even routine cumulative updates can have downstream interactions with firmware, drivers and hardware implementations — particularly in the fast-moving NVMe/DRAM-less SSD segment.

---

What users are seeing: symptoms and scope​

Typical symptom set​

• Drives disappear from File Explorer, Disk Management and Device Manager during or immediately after a large, sustained file write.
• SMART attributes are temporarily unreadable by the OS while the drive is in the failed state.
• Rebooting often restores drive visibility, but performing the same heavy write triggers the problem again.
• In some tests, the partition becomes inaccessible after reboot (drive shows but partitions are damaged) — meaning file corruption or data loss is possible.
• Multiple SSD vendors and some HDDs have been mentioned in community reports, but the highest concentration of reports identify drives using Phison controllers, especially DRAM-less models, as showing failures at lower write volumes.

Which systems appear most at risk​

• Machines performing sustained sequential writes (game installs, large archive extraction, backups to local SSDs).
• Drives at moderate to high capacity usage; community repros often used drives that were ~60% full.
• SSDs based on specific controller firmware variants; DRAM-less designs where host-side memory or caching behaviors are more heavily relied upon seem more susceptible.
• Systems where device firmware has not been recently updated.

How widespread is this?​

The issue appears to be concentrated around particular workloads and controller/firmware combinations. Early public reporting came from individual testers and community forums; a number of independent technology outlets and testers reproduced or reviewed the reported behavior. At the time of initial reports, evidence suggested the problem was not universal across all drives or all PCs, but real enough to warrant caution — particularly for anyone who routinely performs large sequential transfers or relies on a single SSD for primary storage without current backups.
Because this type of fault can lead to permanent corruption, even isolated reports should be treated seriously.

---

Technical analysis: what’s likely happening​

Host Memory Buffer (HMB), DRAM-less SSDs and controller stress​

Modern NVMe SSDs use several techniques to optimize performance and endurance. One common approach for smaller/cheaper SSDs is to use a DRAM-less design: the drive offloads some caching or mapping structures to the host system via the Host Memory Buffer (HMB) feature of the NVMe standard. HMB allows the SSD controller to allocate a region of system memory to serve as a cache, improving performance without an onboard DRAM chip.
The interaction under investigation appears to occur during heavy sustained writes, where the controller is stressed and the device’s caching and mapping logic is heavily exercised. In some reports, the OS-side behavior that manages the HMB or other cached buffers appears to regress or leak memory when certain update code paths are present, which could lead the controller to receive incorrect or incomplete memory mappings. The end result: the controller can enter a state where it no longer responds correctly to NVMe commands, Windows no longer enumerates the device properly, and SMART becomes unavailable.

Driver and kernel interaction​

The failure pattern (disappearing drives, temporary recoverability after reboot, recurrence under same workload) suggests a kernel- or driver-level regression rather than a pure hardware fault — at least in many of the reproduced cases. Candidate subsystems include:

• The OS NVMe driver and its HMB allocation logic.
• StorPort/AHCI layers or the stornvme driver stack in Windows that mediate storage I/O and memory mapping.
• A possible leak or corruption in OS-buffered cache regions that eventually causes the device to fail under sustained pressure.

However, not every affected device uses HMB in the same way, and some HDDs have also been reported to show related symptoms under intense writes, indicating the issue could be broader than HMB-specific logic.

Why DRAM-less/Phison designs may show up more​

Phison is a widely used SSD controller vendor, particularly for consumer NVMe SKUs and lower-cost drives that may forego onboard DRAM. Those designs rely more heavily on HMB and controller firmware efficiency, so any regression in the OS HMB allocation or driver interaction may hit them harder. This doesn’t mean Phison controllers are inherently defective — only that they occupy a larger portion of the risk surface for this exact class of regression.

---

Strengths and limitations of the evidence​

• Strengths:
• Reproducible patterns: independent testers posted step-by-step reproductions that consistently triggered failures under similar conditions.
• Multiple reputable tech outlets covered the issue and analyzed the reported test logs and symptomology.
• Vendor statements (from controller vendors) indicated they were aware and investigating, which adds credibility to the claim that something in the update can interact poorly with particular firmware/driver combinations.
• Limitations:
• The reports are still largely driven by community tests and early reporters; the issue did not (initially) appear as a broad, global outage affecting the majority of Windows 11 users.
• Microsoft’s public KB for the update initially listed no known issues matching these exact symptoms; enterprise-grade telemetry has not been publicly shown to indicate mass impact.
• Some reporting originated from a single thorough tester whose test methodology influenced how the problem was characterized; broader population-level confirmation was limited at the outset.
• Region-specific reproduction was suggested in a few threads, meaning the exact combination of device firmware, motherboard firmware, drivers and localized update packages might change the outcome.

Because of these limits, the most conservative and correct posture is caution: treat the reports as credible and actionable until proven otherwise, and use conservative update practices in production environments.

---

Immediate advice for users (prioritized)​

• Back up critical data now. Copy essential files off of any drive you cannot afford to lose — external HDD/SSD, network storage, or cloud. If you rely on a single NVMe device for critical data, assume the possibility of data loss during large writes until your hardware and OS are shown to be safe in your environment.
• If you have not installed the August 12, 2025 cumulative update (KB5063878) and you perform heavy writes or use Phison/DRAM-less drives, consider pausing Windows Update temporarily and delaying installation until vendors and Microsoft confirm the fix or you are confident via vendor firmware updates. Enterprises should place affected models on compatibility holds and test in a lab before broad deployment.
• Update SSD/HDD firmware and vendor tools immediately where updates are available. Many vendors release firmware patches or guidance when their controllers are implicated. Use vendor tools (vendor dashboard or updater) to check the current firmware and apply supplied updates; always follow vendor instructions and back up data before flashing firmware.
• Avoid large, sustained sequential writes on potentially affected drives until you’re confident they are protected. This includes deferred large game installs, big archive extractions, bulk video transfers, local backups to the drive under test, and similar workloads.
• If you’ve already observed a drive disappear or partitions become inaccessible:
• Stop writing to the drive immediately. Continued writes can further damage data structures.
• Do not run aggressive repair tools that write to the drive (some repair attempts can exacerbate damage).
• Create a forensic image of the drive with read-focused tools (ddrescue, or vendor-provided imaging tools) if you have the skillset — this preserves the current state for recovery specialists to analyze.
• Contact the SSD/HDD vendor and, if necessary, a professional data recovery service if data is critical. Drive RMA may be appropriate if a firmware-level failure is suspected.
• If you have already installed the update and are experiencing problems, you can attempt to uninstall the problematic LCU using DISM/wusa or roll back via System Restore if a restore point exists — but these actions are not guaranteed to restore corrupted files. For capacity-consuming or system-level installs, check recovery and rollback guidance from Microsoft and your vendor.
• Consider a temporary registry mitigation only as a last resort and after backups. Community workarounds previously used for related HMB issues included adjusting the HMB allocation policy in the registry. However, registry edits have side effects (performance loss; potential system instability if incorrectly applied) and are not a substitute for vendor firmware fixes. Always export/backup the registry and be prepared to restore.

---

Practical step-by-step: how to pause and protect Windows update installations (concise)​

• Open Settings → Windows Update → Pause updates for 1 week (or use “Advanced options” → Pause until a specific date).
• For managed environments, use Windows Update for Business or WSUS to apply a safeguard hold for affected device models.
• Monitor vendor advisories for firmware updates (download vendor update utilities).
• If you must install the patch, ensure recent full backups are in place first.

---

Deeper remediation and recovery notes​

What to collect before contacting vendors​

If you see symptoms, gather the following and provide to vendor support or your system integrator:

• Exact Windows build and KB installed (e.g., Windows 11 24H2 OS Build 26100.4946, KB5063878).
• SSD model and firmware version (vendor dashboard tools can list this).
• Motherboard BIOS/UEFI version and chipset drivers.
• A concise step-by-step of the workload that triggered the problem (what file, size, whether drive was ~60% full, whether the drive recovered after reboot).
• Event Viewer logs around the time of failure and any storage-related device or controller errors.
• If possible, a short screen-recording or copy of test logs demonstrating reproducibility.

When to involve a recovery service​

If the drive’s partition tables or file system show corruption and the data is mission-critical, avoid repeated consumer-level repair attempts. Image the drive (read-only) and hand the image or device to a professional data recovery service; they are more likely to extract intact data safely. Repeated attempts to repair a drive by untrained hands can reduce the chance of full recovery.

---

What vendors and Microsoft are doing (and should do)​

• Controller and SSD vendors have publicly stated they are investigating controller firmware interactions with recent Windows patches, and some vendors recommended checking or updating firmware.
• Microsoft’s cumulative KB page for the update initially listed no known issues matching these storage symptoms — a common occurrence early in a patch cycle when vendor- or field-reported issues are still being validated by telemetry and engineering teams.
• Ideally, Microsoft would publish a formal known-issue notice (with a “safeguard hold” on affected hardware via Windows Update) while working with vendors on firmware or driver fixes; vendors should provide firmware updates and clear guidance on risk mitigation.

---

Risk assessment: who should be most concerned​

• Enthusiasts and professionals who perform lots of large, sustained sequential writes (game library installs, video editing scratch disk work, local block-level backups) should be careful and treat the update as risky until proven otherwise for their specific hardware.
• Home users with modest intermittent write patterns are less likely to trigger the edge case, but anyone without backups who performs bulk installs should pay attention.
• Enterprises should treat the report as a test-fail scenario: hold updates for affected SKUs, test in representative hardware labs, and distribute vendor firmware updates before mass deployment.

---

Historical context: not the first time HMB/firmware and Windows updates collide​

This is not the first time an update-and-firmware interaction caused widespread user pain. Prior incidents involving HMB and Western Digital / SanDisk models demonstrated that subtle mismatches between OS allocation behavior and SSD firmware can cause crashes, BSODs, or other failures — and those incidents were resolved through combined vendor firmware updates and Microsoft safeguards. The recurrence underscores the fragile interplay between OS driver changes, new usage patterns allowed by OS improvements, and the variation in SSD firmware across the ecosystem.

---

Bottom line: immediate actions and outlook​

• The reports that a Windows 11 24H2 cumulative update can trigger SSD/HDD disappearance and potential file corruption under heavy write conditions are credible enough to demand immediate, practical precautions: back up data now; delay updates on at-risk machines; and update SSD firmware where vendors provide patches.
• For users who have already suffered a failure, stop writing to the drive, image it if possible, and contact the vendor or a data-recovery professional.
• For admins and power users, push the affected models into a test/hold state via your update-management tools and await either a formal Microsoft safeguard or vendor firmware that explicitly addresses the interaction.
• Keep monitoring vendor advisories and Microsoft’s release-health updates. The pattern — kernel/driver/firmware interactions that emerge only under particular workloads — means the fix may be a combination of firmware updates, device driver changes, and possibly a Microsoft patch or rollback for the specific regression.

This episode is a timely reminder of why backups are the fundamental last line of defense. When system-level updates can interact with device firmware in unpredictable ways, the only reliable protection against accidental data loss remains a current, verified backup and a conservative update policy on machines that contain irreplaceable data.

---

Source: [H]ard|Forum https://hardforum.com/threads/report-microsofts-latest-windows-11-24h2-update-breaks-ssds-hdds-may-corrupt-your-data.2042982