Page 1 of 1
Crashing with High memory usage Virtualbox Headless Frontend
Posted: 12. Jul 2022, 15:37
by ch-dv-0111
Hi there,
I tried installing WSL-2 to run Laravel on ubuntu and since then my vagrant machine and other ubuntu based VMs are maxing out their memory and crashing when before they never crashed.
I disabled Hyper-V and uninstalled WSL-2 and disabled it. No joy.
Reinstalled windows and I'm still facing the same issue.
Settings on VB:
VB Version 6.1.34 r150636 (QT5.6.2)
Base Memory 4096 MB
2 CPU
Execution Cap 100%
100GB vdi
Windows Host:
Windows 10 Pro 64-bit 21H2
OS Build 19044.1766
Processor: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz 2.80 GHz
RAM: 32GB
Attached is:
* VB terminal screen shot
* Log from the VM
* Screenshot of memory use for a single VM running and nothing being executed on it.
Any advice would be great or if there is more info you need.
EDIT:
This is the logs from a VM created with Ubuntu 22.04 running on it. Not a vagrant VM. The Vagrant VM running Homestead was deleted when I re-installed Windows.
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 12. Jul 2022, 17:57
by scottgus1
The log shows that the underlying Hyper-V enabled by WSL2 is still enabled. See
HMR3Init: Attempting fall back to NEM (Hyper-V is active)
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 13. Jul 2022, 01:35
by AndyCot
If you need to keep WSl2 enabled and run Virtualbo then try the latest 6.1.35 test build. Make sure you keep all test build files you download in case you need them as Oracle do not keep them for future downloads once updated.
My testing allows me to run WSL2 and VirtualBox with Hyper-V enabled with VirtualBox-6.1.35-152223-Win.exe insallad.
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 13. Jul 2022, 18:36
by ch-dv-0111
I had followed these instructions previously with no avail (bcdedit, DISM, control panel setting, features etc). Thank you scottgus1 for pointing out the log info I was looking for to know if Hyper-V was still enabled or not. That helped my investigation.
I ended up following this guide
{link removed by mod} and the step that worked for me was to turn off secure boot. Even though I only partially followed it, it was enough.
The Steps I took that resolved it were:
1. I entered the BIOS and turned off secure boot.
2. Turning on I was presented with the request to enter my BitLocker recovery key but instead I skipped the drive and returned to the troubleshooting section and entered the BIOS again
3. Turned back on secure boot.
4. restarted and Hyper-V was fully removed this time
AndyCot wrote:If you need to keep WSl2 enabled and run Virtualbo then try the latest 6.1.35 test build. Make sure you keep all test build files you download in case you need them as Oracle do not keep them for future downloads once updated.
My testing allows me to run WSL2 and VirtualBox with Hyper-V enabled with VirtualBox-6.1.35-152223-Win.exe insallad.
As I don't want to keep WSL2 at all I just fully removed it.
Thanks for the help everyone!
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 14. Jul 2022, 10:59
by mpack
Secure boot has nothing to do with hardware virtualization.
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 14. Jul 2022, 22:22
by fth0
mpack wrote:Secure boot has nothing to do with hardware virtualization.
Well, yes and no. There is a connection between
Secure Boot and Hyper-V you may not be aware of:
Several of the Windows security functions (e.g. HVCI), which use the Hyper-V hypervisor, disable themselves when
Secure Boot is disabled, because the
Virtualization-Based Security (VBS) isn't achievable then. Personally, I never recommended disabling
Secure Boot, because it disables even more Windows security functionality than "only" the hypervisor-based ones.
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 14. Jul 2022, 23:25
by scottgus1
As far as I can see, the Petri link that ch-dv-0111 posted, which is also in the "Hyper-V is Active" tutorial, recommend only a temporary turning off of Secure Boot, but to turn it on again later:
if Secure Boot is enabled, you’ll be prevented from removing Hyper-V because some Windows security features depend on virtualization.
How to Temporarily Disable Secure Boot
To work around this issue, temporarily disable Secure Boot. How you access UEFI settings is system dependent but it usually involves rebooting and pressing a designated key when the system starts, like F12 or ESC. In the UEFI settings, if the system supports Secure Boot, you should find an option to turn it off.
Once you’ve disabled Secure Boot, restart the system. And then restart it again. Now check the status of Hyper-V using systeminfo.exe. You should see that Hyper-V has been disabled. Reboot once more and reenable Secure Boot.
I wonder if this Secure Boot thing is the reason why a few folks report being unable to disable Hyper-V on their hosts at times despite going through the tutorial.
Re: Crashing with High memory usage Virtualbox Headless Frontend
Posted: 15. Jul 2022, 00:21
by fth0
scottgus1 wrote:As far as I can see, the Petri link that ch-dv-0111 posted, which is also in the "Hyper-V is Active" tutorial, recommend only a temporary turning off of Secure Boot, but to turn it on again later
I have a theory why this works despite turning
Secure Boot on again:
In (relatively

) secure setups, Windows uses a complex chain of trust, starting with UEFI,
Secure Boot,
Secure Launch and the
Virtualization-Based Security (VBS) functions. After
Secure Boot has been turned off, the Windows installation could be compromised, so the chain of trust is broken and cannot be re-established by turning
Secure Boot on again. Therefore, I'd assume that Windows memorizes somewhere deep in the registry if
Secure Boot has ever been turned off.
scottgus1 wrote:I wonder if this Secure Boot thing is the reason why a few folks report being unable to disable Hyper-V on their hosts at times despite going through the tutorial.
I don't think so, because having
Secure Boot enabled doesn't stop me from disabling all Hyper-V usages. I'd rather attribute the users' problems to the independence of
HVCI (Memory Integrity) and the
hypervisorlaunchtype setting. The latter doesn't prevent the hypervisor from being used in all cases, as I have verified several times myself.