The nt!HvlEnlightenments flag in the Windows kernel is set to 0 in ENBD, nVidia, and on Kostiantyn’s reproducer.
 
The flags can be checked in the dump with the command (this dword - so four bytes)
3: kd> dd nt!hvlenlightenments
fffff806`4430141c  00000000 7d4e7200 ffffd181 00000000
 
What kind of implication does it have?
 
Here is a snippet from the kernel memory function MiFlushTbList
 
.text:0000000140201241                 mov     eax, cs:HvlEnlightenments
.text:0000000140201247                 test    al, 40h
.text:0000000140201249                 jz      loc_140070F10
.text:000000014020124F                 call    KiCheckVpBackingLongSpinWaitHypercall
.text:0000000140201254                 test    al, al
.text:0000000140201256                 jz      loc_140070F10
.text:000000014020125C                 mov     ecx, edi
.text:000000014020125E                 call    HvlNotifyLongSpinWait
.text:0000000140201263                 nop
.text:0000000140201264                 jmp     loc_140070F12
 
This can be translated to C
if(HvlEnlightenments & 0x40) // If 6 bit is set, then execute the code below
{
   BOOL v = KiCheckVpBackingLongSpinWaitHypercall(...)
   if(v)
 

}
 
So enlightenments are not working - it means that the kernel is handling things in not-enlightened way.
 
All flags are set to zero in ENBD, nVidia, and on Konstanin’s reproducer.
 
We’ve asked ENBD to grab a dump from a fresh installation where they don’t see BSODs to compare the flags and validated if this is the key factor.