VirtualBox

Ticket #16801 (new defect)

Opened 3 years ago

Last modified 6 months ago

Running a Virtual Machine when Windows Hyper-V is enabled should NOT Crash Windows

Reported by: aplatypus Owned by:
Component: VMM Version: VirtualBox 5.1.22
Keywords: Cc:
Guest type: all Host type: Windows

Description

VirtualBox can not run on Windows 10 when Hyper-V mode is ACTIVE (ON). However the existing behaviour is pathological and must be corrected.

Running a VM when Hyper-V is ON causes the BSOD!

Conditions:

  1. Windows boots with Hyper-V enabled
  2. Start-up VirtualBox Manager GUI
  3. START an existing VM

Outcome:

  1. VM begins to load
  2. The dread Windows BSOD (Blue Screen of Death) appears
  3. Windows dies -- generates crash log, etc.
  4. Windows reboots
  5. NOTE: Hyper-V is still active and must be deactivated manually.

Resolution Sought:

  1. Check for Hyper-V mode is: OFF, at start-up for all VirtualBox tools; especially:
  1. Issue a WARNING pop-up or error message for command line Reporting that Hyper-V mode is active and VirtualBox cannot run while there is another hypervisor active. Or some such.
  1. Exit the VirtualMachine (shell) once the Hyper-V Active status is reported.
    • Thus Avoiding the BSOD

Optional / suggestion:

  • It would be useful for the warning to tell users how to disable/enable Hyper-V as part of the warning message(s).
  • Another helpful feature is for the VirtualBox management GUI to turn Hyper-V off or on from a menu.

Related / supplementary notes:

There seem to be several issues that mention Hyper-V troubles. Some are real bugs and some look like misunderstandings.

In my opinion no software should cause a system crash-dump when it can be prevented by checking some system configuration attributes.

See also:

Change History

comment:1 Changed 3 years ago by socratis

Related tickets: #15780, #15984, #16013, #16675 and #16832.

comment:2 follow-up: ↓ 3 Changed 3 years ago by noncreature0714

Concur with this bug. Cannot run Docker Swarms using Virtualbox on Windows because of this bug. Albeit it is probably a Windows issue causing the crash, there is zero warning and then total BSOD, which is something the VirtualBox community should fix.

Last edited 3 years ago by noncreature0714 (previous) (diff)

comment:3 in reply to: ↑ 2 Changed 3 years ago by socratis

Replying to noncreature0714:

it is probably a Windows issue ... which is something the VirtualBox community should fix.

it is probably a Windows issue which is something that Microsoft should fix and VirtualBox implement a workaround until it gets fixed.

Describes the situation a little bit more... appropriately. ;)

comment:4 Changed 3 years ago by noncreature0714

Apologies for airing my frustrations. I'm trying to advocate for Docker adoption (and, indirectly, VirtualBox per [following Docker's documentation](  https://docs.docker.com/get-started/part4/#set-up-your-swarm)) within my company, and this defect is a critical blocker for planned demos. It's definitely, and [ironically](  https://www.docker.com/microsoft), Microsoft's fault.

comment:5 follow-up: ↓ 6 Changed 3 years ago by aplatypus

Several comments are off-point. As I understand it the hardware can only cope with one hypervisor at at time. Docker (now) can either run on the Micrsoft Hypervisor or the VirtualBoxy hyper visor. It is our choice (afaik).

My point is that the ViretualBox application program ought to be defensive and verify that it was started in a compatible environment (vis. non-Hyper-V). Imho, a program ought not willingly proceed knowing that the BlueScreen of Death is the outcome. At the very least, the pop-up message could as if the user wants to go a head, damn the torpedoes *lol*

I suppose an alternative would be to arrange things such that one can have multiple hypervisors running at the time time. That is definitely NOT the remedy sought.

comment:6 in reply to: ↑ 5 Changed 3 years ago by socratis

Replying to aplatypus:

As I understand it the hardware can only cope with one hypervisor at at time.

Not really, they could run in "parallel", sharing resources. See below.

I suppose an alternative would be to arrange things such that one can have multiple hypervisors running at the time time.

It could be in theory and that's the whole idea. You go VM-entry, execute guest, VM-exit. Cooperatively. Unfortunately MS launches Hyper-V at boot time as a service and keeps a hold of the VT-x, regardless of use or not. As you noted in your original report as well, VirtualBox has to find a way around it, and that's why I proposed to close the rest of the tickets as duplicates, because yours had the best description and a potential workaround.

comment:7 Changed 3 years ago by dzmitry.lahoda

I have same concerns. My scenario I need to develop Xamarin Mobile Applications which require HyperV with Visual Studio by default and have VirtualBox instance for other usages. I hope for button to disable HyperV when I start VirtualBox. I have done analysis, and this is one of main pain points and drawback of using VirtualBox on Windows, so one vote for full HyperV way. Another one is 3D/GPU support.

comment:8 Changed 2 years ago by Ajedi32

Don't see any obvious way to vote on this or add myself to the CC list so... +1 I guess?

Programs should most definitely _not_ trigger BSOD during normal operation. If VirtualBox is not capable of running alongside Hyper-V it should just say so, not crash the entire machine.

comment:9 Changed 2 years ago by Schroeffu

Is there any update? Nobody cares..? Have had to remove Hyper-V to run Virtualbox, but that's not the goal..

comment:10 Changed 2 years ago by socratis

@Schroeffu

This is a problem with Hyper-V being too aggressive and not releasing VT-x once it's got a hold of it. VMWare and VirtualBox for example can not only coexist, but they can run concurrently. Not so with Hyper-V.

But the question is: are you getting a crash? Because this is what this ticket is about, not the ability to have both of the virtualization programs installed...

comment:11 Changed 16 months ago by colbycdev

I'd like to note there is no longer an easy way to disable Hyper-V. You have to also disable Device Guard And Credential Guard with a special tool from Microsoft, which also reduces security. You also cannot enable Core Isolation, and Windows Virtual Machine Platform as well as Hyper-V. So now, Windows 10 in it's default configuration id dependent on Hyper-V. My understanding is Microsoft has introduced an API to work with Hyper-V as well, so running two hypervisors at once should no longer be an issue (?)

The build of VirtualBox v6 was supposed to resolve this, but Windows 10 Build 18950 still crashes with "HYPERVISOR ERROR" whenever I start a VM

Really hoping fro a resolution for this, as I need a few different virual machines for testing/debugging purposes

comment:12 Changed 16 months ago by colbycdev

I should clarify that Windows Virtual Machine Platform is enabled by default

comment:13 Changed 9 months ago by CleverCoderX

+1 I guess (also)?

comment:14 follow-up: ↓ 16 Changed 8 months ago by paulstelian97

User of Hyper-V and Virtualbox here: Virtualbox 6.1.4, Windows 10 version 1909 Pro. I have a Hyper-V vm and 64-bit Virtualbox VM (also tried a 32-bit one in parallel with the two, also works) successfully running in parallel. Was getting errors with latest 6.0. Everyone should attempt to get the latest version (6.1 or later) and retry. This version has a working Hypervisor Platform implementation.

Last edited 8 months ago by paulstelian97 (previous) (diff)

comment:15 Changed 7 months ago by dtpoirot

...how well does that work with Windows 10 Home Edition or with a corporate machine with a group policy which prohibits Hyper-V?

comment:16 in reply to: ↑ 14 ; follow-up: ↓ 18 Changed 6 months ago by vatsan

Replying to paulstelian97:

User of Hyper-V and Virtualbox here: Virtualbox 6.1.4, Windows 10 version 1909 Pro. I have a Hyper-V vm and 64-bit Virtualbox VM (also tried a 32-bit one in parallel with the two, also works) successfully running in parallel. Was getting errors with latest 6.0. Everyone should attempt to get the latest version (6.1 or later) and retry. This version has a working Hypervisor Platform implementation.

Just tried installing VB v6.1.8 on Windows 10 Pro (build 1909) with Hyper-V and "Windows Hypervisor Platform" enabled. Attempted to install Lubuntu 20.04 x64 guest but the guest OS blacks out after file system check. I was staring at the black guest OS screen for quite a few minutes with nothing happening. In short, VB is still not working with Hyper-V enabled Windows 10.

Am I missing something crucial here?

Thanks and rgds, Vatsan

comment:17 Changed 6 months ago by Vp

Today I got BSOD. I had installed latest docker for windows10 on my office laptop.i also have virtual box 6.1.4 installed . After successful docker installation ( which needs Hyper-v to be enabled ) my laptop crashed with a Bsod as soon as I started a VM in virtualbox. As a fix I had to disable hyper-v on my host machine and uninstalled docker.

comment:18 in reply to: ↑ 16 Changed 6 months ago by georgn

Replying to vatsan:

Just tried installing VB v6.1.8 on Windows 10 Pro (build 1909) with Hyper-V and "Windows Hypervisor Platform" enabled. Attempted to install Lubuntu 20.04 x64 guest but the guest OS blacks out after file system check. I was staring at the black guest OS screen for quite a few minutes with nothing happening. In short, VB is still not working with Hyper-V enabled Windows 10.

I'm using VirtualBox 6.1.8 on Windows 10 Enterprise insider (build 19613). I just enabled Hyper-V to play with the WSL 2 and after reboot my Ubuntu 20.04 VM had an exception on restart. Rebooting the VM showed the usual goodness but black screen around the time gnome takes over.

comment:19 Changed 6 months ago by georgn

Some additional info on the black screen... the other tty sessions are available and I was able to do a text login and get at dmesg which I can't copy-paste but the upshot is that gnome-shell is suffering some "general protection faults" in:

vmwgfx_dri.so:[7fb8bea73000+d48000]
vmwgfx_dri.so:[7f7fcea73000+d48000]
vmwgfx_dri.so:[7fd509a71000+d48000]

comment:20 Changed 6 months ago by georgn

Last bit of info... turning off 3D acceleration on the guest solves the black screen (which for me is fine).

Spoke too soon -- makes actually using the thing very slow and clunky (as in pause, purple flash, redraw screen on a windows raise).

Last edited 6 months ago by georgn (previous) (diff)

comment:21 Changed 6 months ago by fgireu

I positively confirm this issue with VB 6.1.8, Intel NUC5i5RYK (Bios 0384 with virtualization extensions enabled), host Windows 10 (1909) with Hyper-V enabled: Virtualbox VMs for Windows run unreliably. That's both pre-existing and new VMs, set for the default paravirtualization. Issues include but ere not limited to: an install of Windows 10 2004 from iso image fails repeatedly at a random point in the install (freeze, BSOD, account of corrupt file..).

Disabling Hyper-V and rebooting (once after disabling, another as a precaution for the reason stated below) fixes it perfectly.

I had previously met an incompatibility with Hyper-V like a year ago, but symptoms have changed to the worse: then Virtualbox crashed, thus one would suspect the host. Now it does not, and one first suspects the VM. At that time, I had determined with high certainty that after disabling Hyper-V it was necessary to reboot the Windows host TWICE.

Last edited 5 months ago by fgireu (previous) (diff)
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use