The text that was printed later on is a red herring, by the way. Configuring VirtualBox with an appropriate serial device and bootstrapping with a serial console would be another. Persuading the boot loader to switch the screen into, say, 50 line mode would be one way of doing this.
Without it, you cannot fully diagnose this problem beyond some unknown program did something unknown that caused an illegal instruction signal to be raised. You need to find out what was printed that has scrolled off the top of your screen. It could be Comm: sh, or Comm: init, or even Comm: run-init as in the AskUbuntu question that you linked to in your question. That said - VMs in VirtualBox should work when the Windows Hypervisor is enabled, but any seriously complicated software has bugs, and this is an entirely different code path than when VirtualBox uses its own hypervisor code which isn't possible when Microsoft's is active.This panic screen - which you have not transcribed in full in your question but really should so that the text will be indexed and people will find it in the future - is the panic screen that results when process #1 exits after not handling signal #4 (illegal instruction).Īs I just explained at, some of the important information has scrolled off your screen, namely the Comm: line that tells us what program was running as process #1. Memory integrity in the Device Guard area), see e.g. The usual reasons why it is enabled (without you having enabled Hyper-V) is that your Windows 11 config uses the HVCI feature (a.k.a. the log showsĠ0:00:02.591516 HM: HMR3Init: Attempting fall back to NEM: VT-x is not availableĠ0:00:02.647880 NEM: info: Found optional import WinHvPlatform.dll!WHvQueryGpaRangeDirtyBitmap.Ġ0:00:02.647936 NEM: WHvCapabilit圜odeHypervisorPresent is TRUE, so this might work. Your Windows 11 install has the hypervisor itself enabled somehow.
0 kommentar(er)
