Win11 LTSC guest crushing

[yaro]

I'm fairly new to VirtualBox and can't really figure out myself what's causing these what seems like random crushes of my VM which come in least favorable momets. I attached the logs. Perhaps someone could point me to what needs changing in config to make it stop crushing.

[yaro]

I could really use some help here. This VM keeps crashing a lot and I don't see any obvious symptoms on host side.

[multiOS]

Sorry you haven't had an earlier response condidering the number of log downloads.

It looks as if something complex is causing your problem and the final problem may be from an accumulation of issues, but will try to explain what I see.

The final issue/outcome is a GURU Meditation error following a display problem:

00:01:02.175261 GUI: UIFrameBufferPrivate::IsVideoModeSupported: Mode: BPP=32, Size=1920x1440 is NOT supported
00:01:02.176370 VMMDev: Guest Log: VBoxMP::vboxWddmVModesAdd: WARNING! :resolution 1920x1440 not accepted by the frontend
00:01:02.178897 VMMDev: Guest Log: VBoxMP::DxgkDdiStartDevice: WDDM: VRAM 0xe0000000/0x8000000, FIFO 0xe8400000/0x200000, IO 0xc030/0x10
00:01:02.180722 Enabling different vbva mode
00:01:02.182739 Enabling different vbva mode
00:01:02.187211 VMMDev: Guest Log: VBoxMP::DxgkDdiQueryAdapterInfo: WARNING! :unsupported Type (47)
00:01:07.805635 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'
00:01:07.805674 Console: Machine state changed to 'Stuck'
00:01:07.806248 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:01:07.806250 !!
00:01:07.806250 !! VCPU1: Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)
00:01:07.806306 !!
00:01:07.806312 !! Skipping ring-0 registers and stack, rcErr=VINF_EM_TRIPLE_FAULT
00:01:07.806315 !!
00:01:07.806315 !! {mappings, <NULL>}
00:01:07.806316 !!
00:01:07.806324 !!
00:01:07.806324 !! {hma, <NULL>}
00:01:07.806325 !!
00:01:07.806326 !!
00:01:07.806326 !! {cpumguest, verbose}
00:01:07.806327 !!

Thi type of error is similar is similar to a Windows 'Blue Screen of Death' and it can be equally difficult to determine the clear reason for the problem, as 'TRIPLE_FAULT' errors normally means that VirtualBox is unable to identify/recover from the actual cause(s).

Possible cotributory factors include an earlier encountered issue in the log:

00:00:18.609727 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
00:00:18.738089 NEM: info: Found optional import WinHvPlatform.dll!WHvQueryGpaRangeDirtyBitmap.
00:00:18.738111 NEM: info: Found optional import WinHvPlatform.dll!WHvResumePartitionTime.
00:00:18.738121 NEM: info: Found optional import WinHvPlatform.dll!WHvSuspendPartitionTime.
00:00:18.738130 NEM: info: Found optional import WinHvPlatform.dll!WHvRequestInterrupt.
00:00:18.738138 NEM: info: Found optional import WinHvPlatform.dll!WHvGetVirtualProcessorXsaveState.
00:00:18.738147 NEM: info: Found optional import WinHvPlatform.dll!WHvSetVirtualProcessorXsaveState.
00:00:18.738158 NEM: info: Failed to import WinHvPlatform.dll!WHvGetVirtualProcessorState: VERR_SYMBOL_NOT_FOUND
00:00:18.738184 NEM: info: Failed to import WinHvPlatform.dll!WHvSetVirtualProcessorState: VERR_SYMBOL_NOT_FOUND
00:00:18.738194 NEM: info: Found optional import WinHvPlatform.dll!WHvGetVirtualProcessorInterruptControllerState.
00:00:18.738203 NEM: info: Found optional import WinHvPlatform.dll!WHvSetVirtualProcessorInterruptControllerState.
00:00:18.738211 NEM: info: Found optional import WinHvPlatform.dll!WHvGetVirtualProcessorInterruptControllerState2.
00:00:18.738220 NEM: info: Found optional import WinHvPlatform.dll!WHvSetVirtualProcessorInterruptControllerState2.
00:00:18.738229 NEM: info: Found optional import vid.dll!VidGetHvPartitionId.
00:00:18.738238 NEM: info: Found optional import vid.dll!VidGetPartitionProperty.
00:00:18.738333 NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...
...
00:00:18.743719 PGM: Enabling NEM mode
00:00:18.744068 NEM:
00:00:18.744069 NEM: NEMR3Init: Snail execution mode is active!
00:00:18.744069 NEM: Note! VirtualBox is not able to run at its full potential in this execution mode.
00:00:18.744070 NEM: To see VirtualBox run at max speed you need to disable all Windows features
00:00:18.744070 NEM: making use of Hyper-V. That is a moving target, so google how and carefully
00:00:18.744070 NEM: consider the consequences of disabling these features.
00:00:18.744071 NEM:
00:00:18.744118 CPUM: No hardware-virtualization capability detected

If VirtualBox cannot directly access Intel's VT-x (hardware acceleration) support then that can result in a significant slowdown in VM performance. A relatively common cause of this issue on Windows 10/11 hosts is Microsoft's default activation of it's virtualisation-based security features in Windows 10/11

There are also a couple of configuration issue which could have a negative impact, First:

00:00:18.608707 NumCPUs <integer> = 0x0000000000000004 (4)
...
00:00:20.592941 CPUM: Logical host processors: 8 present, 8 max, 8 online, online mask: 00000000000000ff
00:00:20.592944 CPUM: Physical host cores: 4

Allocating 4 CPU's to the VM gives it access to all 4 of the Hosts Physical CPUs which may cause some performance issues if the Host is using significant resources. Personally I would not allocate a Windows 11 Guest more than 2 CPUs unless it is likely to used for some continuously intensive data processing tasks.

and lastly, your VirtualBox configutation shows that the VM's essential support files are located in the usual default location on the C: Drive:

- C:\Users\<UserName>\VirtualBox VMs

but the VDI file file appears to be stored on a separate (external?) Drive 'G:\VBox\LSTC\LTSC11.vdi'

This makes effective VM Backup a more complex task than it ought to be, but also raises the question(s): Is G: an external drive and, if so, what type of Drive is it (HDD/SSD/something else) plus how is it connected to the Host Sytem (USB2/3?) as data transfer volume/speed are likely to have an impact if the drive and/or connection method are 'slow by modern standards'. I'm not specifically criticising the use of an external source as gthe default for VM's as I change my default 'VirtualBox VMs' storage to an external SSD connected via USB-C 3.2/Thunderbolt but, for performance reasons, wouldn't consider using an HDD or any external connection less than USB3.0.