![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
It seems as if the problem stemmed from a change related to HBM Policies, more specifically how the operating system designates how much HBM cache will the NVMe drive need. Windows 11 24H2, as compared to 23H2, allocates a maximum of 256MB of unified cache for DRAM-less NVMe drives, that are WD SN770 and SN580 respecively. While SN580 supports the allocation of 200MB of cache, SN770 does only 64MB. In either case, allocating more cache than is allowed by the manufacturer's firmware results in a stall and subsequent R/W failure (as uncovered by a WD customer, Snailium).
The problem was thoroughly analysed and talked through in the aforementioned thread, unveiling a bandaid fix in a form of a registry tweak. The tweak in question was also tested on a variety of hardware configurations, and was proven successful at rectifying some of the issues WD customers were having. However, that doesn't necessarily mean that all issues were fixed by the said tweak, as some WD users expressed their dismay with the problem, despite having gone through all the tweaking work.
Microsoft has to patch the HMB table in order to resolve improper allocation of the memory as cache.