These new drivers are more aggressive in some way that is provoking memory related bsods and Device Loss crashes in D3D12 and Vulkan, This is not a Driver Bug pər-ˈsē, the prevailing crash dumps are either revealing off by one bit errors in the UMD (Device Loss source), or in critical kernel drivers (BSOD Source). Off by one bit errors can be antagonised by software operating more aggressively, but they are not software caused, the error can be caused in 2-3 different ways, one is the CPU tells IMC to write Value X but it Writes value Y because of signal noise on the trace between imc and memory another is the Value in memory corrupts on row refresh and another concerns the Command Rate, where a latch times out on the first bit and its never written in the first place. At this point, I suspect the onslaught of users playing DSR and RDR2 that are encountering crashes have hit this stability concern and need to tweak their system timings from the start, and it also means that some people are going to be pissy because their expensive XMP ram is not stable, and likely never ever was. Let me leave off with a reminder that when you deviate from the specifications the CPU vendor lists on the CPU's support page, the system is in the stability grey area, no board vendor or cpu vendor can guarantee the stability of "Performance Memory" or a minor cpu overclock across Kernel driver updates, the OS itself or when taken into context against the CPU's own Eratta. For Context, my own home theatre build which I have overclocked and was using 1N command rate for the last year stable, became unstable with the 535.98 update. It is stable again with CR2, please confirm your system configurations before reporting bugs, a driver can and often does reveal system weaknesses in the wake of significant alterations deep in the driver, and it is incredibly unlikely that a memory management bsod with the parameter 0x401 - 0x403 is software caused.