Virtual box crashes on Windows host.

[wjw1964]

Hmm, I assume your comment relates to the number of CPUs. I'm using Windows 8.2 VMs, they lockout with multiple CPUs it seems. I'm not sure I understand how having more CPUs avoids the VMs aborting.

None of this was a problem on my previous Windows 10 (Surface) laptop, I was running VirtualBox 6.12.

I can only guess the new DELL whatever it is with Windows 10 has some quirk or another. I was forced to 6.16 to even get the VMs to start.

From what you are saying Windows is making it harder and harder not to use HyperV

[scottgus1]

Hmm, I assume your comment relates to the number of CPUs.

No I was actually talking about just the two posted by Mpack and myself just above your post:

Restarting the PC is not an optional part of the instructions.

Please post a new log not showing "Attempting fall back to NEM".

None of my Windows 10 hosts runs Hyper-V, and they work fine. So far we haven't seen full following of the tutorial. When the tutorial is followed properly, Hyper-V takes a nap.

[wjw1964]

I have repeatedly run the commands:
bcdedit /set hypervisorlaunchtype off

DISM /Online /Disable-Feature:Microsoft-Hyper-V

and then stopped the laptop. I could be guilty of drifting off the plan by running these above commands post-boot as well.

This time I have exactly, run the commands, stopped the laptop. Started the laptop and started the VM. I got thru the day, next morning (the laptop probably went to sleep at some as it was off power for an hour) the VM aborted. Log attached.

[fth0]

Shut down the Windows OS by holding the Shift key when selecting "Shut down" from the Windows Start Menu.

[wjw1964]

Thanks fth0.

I have shutdown and started, then run the commands and shutdown with the shift also depressed, then started.

There seems some correlation to when my laptop goes to sleep. That doesn't happen that frequently as I'm working from home with COVID. I do move between "home" locations and then the laptop sleeps.

Log attached.

[fth0]

Log attached.

No, you didn't.

[wjw1964]

Sorry

[wjw1964]

File was too large. Now compressed.

[mpack]

No change.

00:00:03.411521 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
00:00:03.463769 NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...

[wjw1964]

Ok, still a problem. The best I can do is run these commands:
bcdedit /set hypervisorlaunchtype off

DISM /Online /Disable-Feature:Microsoft-Hyper-V

each day, preferably with the VMs down. I seem to then get thru the day and in the morning the second I use the paste buffers there will be an error and they abort.

Doesn't matter if I reboot after running these commands and shift shutdown seems no better. The VMs make it thru the night but died soon afterward.

[mpack]

Changing boot options (i.e. bcdedit) is pointless unless you intend to reboot, since that is the only time the options are applied.

[wjw1964]

OK, I'll skip the bcdedit then.

I have rebooted more than a few times with the commands and seen that it doesn't help.

[mpack]

bcdedit is required to fix the problem, following by a required hard reset. Contact your laptop vendor for advice on how to do the second part. It will work if done properly.

From my reading of the shutdown command, it should be possible for you to open an admin command console and type: "shutdown /s /t 0". Or, hold down the shift key while selecting "Shutdown" from the Win10 start menu power options.

[multiOS]

I could be completely off track, but is there a chance that Windows Fast Start is enabled on the Laptop? If yes, that might prevent the bcdedit command from having the desired effect as it is similar to a 'Save State' in VirtualBox.

[fth0]

I could be completely off track, but is there a chance that Windows Fast Start is enabled on the Laptop? If yes, that might prevent the bcdedit command from having the desired effect as it is similar to a 'Save State' in VirtualBox.

We've already covered that aspect (twice): Both holding the Shift key while selecting "Shutdown" and using the "shutdown /s /t 0" command will prevent Fast Startup from kicking in. Deliberately crashing the running Windows would be a 3rd alternative, albeit a more dangerous one.