2024-01-10
Using windbg (installable using winget) it is possible to analyse crash dumps stored in C:\Windows\Minidump (or sometimes %SystemRoot%\MEMORY.DMP). All dumps had the same issue. I dug around, and tried disabling WSL2 and Hyper-V. But apparently Windows uses the hypervisor also to tighten security. So I found the Microsoft page Virtualization applications don't work together with Hyper-V, Device Guard, and Credential Guard. And that one linked to the Microsoft docs on virtualization based security.
There it was stated that in the registry (using regedit) the following keys should be removed (both):
Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
Key name: EnableVirtualizationBasedSecurity
Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
Key name: RequirePlatformSecurityFeatures
In msinfo.exe you can see if Virtualization based securtity is enabled. If it is still enabled, you can also disable it using using the Local Group Policy Editr (search for gpedit) and go to Computer Configuration / Administrative Templates / System / Device Guard. Set 'Turn On Virtualization Based Security' to disabled.
This solved all my HYPERVISOR_ERROR problems. It seems a Windows auto update went wrong tonight (CLOCK_WATCHDOG_TIMEOUT), but I suspect that is unrelated to the hypervisor error I got earlier. I hope it helps some people, because I did not find anything on internet on this.
UPDATE 2024-01-15 I reached out to Microsoft support and send in the device for replacement. The replacement was approved, so I will test again if I get the device back.
UPDATE 2024-01-23 The device has been replaced and been running flawless for 4 days (with multiple VMs, WSL2, and a Windows GitLab runner). So I guess it was a hardware problem after all?
See Windows Dev Kit 2023 for more information on the dev kit.