ntdll:exception crashes some Windows 10

[Paul Gofman]

On 12/7/20 17:07, Francois Gouget wrote:
> So I have a problem with ntdll:exception: it crashes the Windows 10 VM I 
> set up on my development TestBot machine. I'd appreciate any insight you 
> may have.
>
> The VM is Windows 10 Pro 64-bit [1] with all updates all the way to 
> 2020-11-03. And the following exception.c lines cause it to crash:
>
>     dreg_test.dr0 = 0x42424240;
>     dreg_test.dr2 = 0x126bb070;
>     dreg_test.dr3 = 0x0badbad0;
>     dreg_test.dr7 = 0xffff0115;
>     run_exception_test(dreg_handler, &dreg_test, &segfault_code, sizeof(segfault_code), 0);
>
> Same thing for the next dreg_handler test a few lines down.
> None of the TestBot's Windows 10 VMs crash when running that code :-(
>
> More data:
> * The crash is 100% reproducible.
>
> * I get a BSOD saying KERNEL_SECURITY_CHECK_FAILURE
>
> * Looking in the event log I found the following:
>
>   The computer has rebooted from a bugcheck.  The bugcheck was: 
>   0x00000139 (0x0000000000000004, 0xffff9f019bff5010, 
>   0xffff9f019bff4f68, 0x0000000000000000). A dump was saved in: 
>   C:\Windows\MEMORY.DMP. Report Id: fb52dedb-eb5e-4010-b0ac-d17284efc806.
>
> * 0x139 does match KERNEL_SECURITY_CHECK_FAILURE. If I understand 
>   correctly its type is 0x4, i.e. reserved, which is not very helpful.
>   https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x139--kernel-security-check-failure
>
> * The online resources are really not helpful. They suggest to:
>   - Check the memory (in a VM? did so anyway, found nothing)
>   - Run chkdsk /f c: (nothing)
>   - Run sfc /scannow (found nothing)
>   - Get the latest drivers. I use the QEmu 0.1.185 drivers (stable 
>     branch, same as the TestBot).
>   - Disable the hyper-v network adapter. I use an e1000e network card 
>     (like in the official TestBot).
>
> * I use qemu 1:5.0-14~bpo10+1, like vm4 which runs w10pro64.
>
> * I use the same hardware configuration as the TestBot except for the 
>   CPU (Haswell-noTSX-IBRS instead of IvyBridge-IBRS) and 4 cores instead 
>   of 3.
>
>
>
> [1] Installed from Win10_2009_English_x64.19042.iso
>
While it looks like a definite VM bug, it is maybe interesting to know
for a start what exactly triggers the error. Is it possible to see if
disabling the setting of the debug registers in dreg_handler() above
(lines context->Dr<n> = test->dr<n>;) avoids the crash, and if yes,
which exactly register(s) setting trigger that. That is, disable setting
all the registers, then check if setting dr7 alone still crashes it
(setting dr7 enables HW breakpoints), and if no, leave dr7 enabled and
enable the others one at a time to see which will trigger the crash.