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...
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.