What happens when a routine security patch cripples both your data recovery tools and, in some cases, the very storage hardware they’re meant to protect? That’s the question facing Windows users this month after a pair of August updates introduced failures in two critical areas: system reset and recovery, and large-scale SSD file transfers.
The initial wave of issues was caused by KB5063875, a Windows 10 22H2 and Windows 11 versions 22H2 and 23H2 security update. It corrupted the operating system’s native Reset and Recovery tools tools meant to return a machine to factory settings or reinstall Windows with file preservation. Once installed, any reset would fail silently, reversing modifications without notice. Microsoft acknowledged the flaw on August 18 and released an out-of-band fix, KB5066189, the following day. The vulnerability also impacted IT administrators employing RemoteWipe CSP to remotely reset devices, a reminder that recovery modes are deeply embedded in enterprise management processes.
The more complicated and potentially harmful issue manifested in Windows 11 24H2 with KB5063878. Reports started coming from users large numbers in Japan whose SSDs disappeared from the system during massive file transfers. Testing conducted by user Nekorusukii demonstrated a consistent trigger: transfers over 50GB on drives over 60 percent full. Of 21 SSDs put to the test, 12 were inaccessible until a reboot, and one, a Western Digital SA510 2TB SATA model, failed to recover at all. The trend was not limited to one manufacturer. Drives from SanDisk, Samsung, WD, and others, based on controllers by Phison, InnoGrit, and even in‑house ones, showed failures.
The root cause implies alterations in the storage stack in Windows and how it interfaces with SSD firmware when subject to long‑term write loads. Certain DRAM‑less NVMe drives depend on system RAM allocations of Host Memory Buffer (HMB) to cache mapping tables. In one technical analysis floating around user forums, Windows 11 24H2 raised HMB allocation to 200MB from 64MB. On some controllers older Phison E12/E16 series in particular this change can trigger DMA faults, and the controller freezes. The OS then logs a “surprise removal,” and SMART data is no longer readable. In SATA models such as the WD SA510, forced write‑cache flushing in these circumstances can cause NCQ timeouts, taking the drive offline.
Phison, whose controllers drive an estimated 40–50 percent of consumer SSDs,, confirmed “industry‑wide effects” from KB5063878 and the previous KB5062660 update, and is “working with partners” to determine affected models and provide firmware updates. Whereas some vendors, including SK hynix, have already worked around these kinds of cache-handling problems in firmware, most cheap and older drives are still at risk. Microsoft has not yet added the SSD bug to its official list of known issues, but acknowledged it is “aware of these reports and are investigating with our partners.”
The size of the risk cannot be gauged. Forum analysts point out that if even 0.01 percent of Phison-based system installations reach the 50GB/60% point, tens of thousands of system crashes might take place worldwide. The truth that the bug has the possibility of bricking a drive’s firmware in some very rare instances making the drive unusable even by UEFI raises the bug from an annoyance to the level of a data-loss incident.
Windows’ update framework does provide some protections, including Known Issue Rollback (KIR) for some regressions, but these are designed mainly to address OS-level issues, not hardware‑firmware interaction. Rolling back KB5063878 is a recourse for impacted users, but only if the machine is still bootable. For admins, the incident highlights the value of staggered deployment of updates, comprehensive backup practices, and knowledge of hardware-specific vulnerabilities.
Until a unified patch comes along, the practical workarounds are blunt but effective: avoid extended writes over 50GB on affected systems, lower drive fill levels under 60 percent, or disable HMB through registry settings to limit allocation at 64MB. In environments where sizeable data transfers are unavoidable game development, media production, or enterprise backup isolating workloads to unaffected drives or OS versions may be the only safe option.
The August patches were intended to plug security holes. Instead, they’ve revealed how a seemingly innocuous modification in memory allocation low down in the storage system can have ripple effects, disabling recovery tools, mashing transfers, and in the worst case, killing the very devices responsible for protecting data.
