virtualbox.org

I have found a solution which helped me to fix problem in 1903. Just run PowerShell as an administrator and execute:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

YuriyVoznyuk wrote:I have found a solution which helped me to fix problem in 1903. Just run PowerShell as an administrator and execute:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Thanks. It works, until Sandbox is enabled, whereas it stops working again...

Cheers.

In the current state the Hyper-V fallback is almost unusuable. I can't get it to work, despite trying everything suggested.
Even if it finally works, we need better error messages
E.g. tell the user clearly which minimum Windows Version is required instead of some cryptic API missing error hidden inside the logs.

I appreciate the work that goes into this! Are any developers reading this?

Not sure if this helps - but VirtualBox is running for me without trying any weird workarounds.
I'm on Windows 10 1803 Build 17134.829
With VirtualBox 6.08 r130520
50

That being said, performance is extrmely slow. Havent properly measured, but easily 1/4 the speed as without hyper-v.
Running these commands to switch hyper-v on/off
bcdedit /set hypervisorlaunchtype off
bcdedit /set hypervisorlaunchtype auto

What worked for me just now is this -
Disabled sandbox (winpro as i was told that uses virtual as well)
Then when I started the session I chose expert mode, that then pointed things to the correct DVL (? think thats the right file extension), after that, it fired up and is running now

Is Sandbox the problem then?

It's one of the problems. See this list in viewtopic.php?f=1&t=62339#p452019

Ummm... It seems still no one knows what's going on behind the scene and we're all shooting in the dark... sometimes A works, A+B doesn't work, A+B+C works, A+C doesn't work......

Cheers.

loyukfai wrote:It seems still no one knows what's going on behind the scene and we're all shooting in the dark...

You won't believe how many times I've wished that there was a tool that would say "Hyper-V is in use by app A, B, C and D". Unfortunately no such tools exists, we have to go by trial and error, shooting in the dark for a moving target...

If VB team is interested in fixing this, please consider making available a data collection tool/methodology for us to report data for further study...

Cheers.

@loyukfai
You don't seem to understand... There's no way to get to that information. It's not about the availability of a tool, it's about the unavailability of the API to get to that information.

If you find it, please let us know, it's an open source project, and all contributions are welcome...

Yes, I do not understand, and appreciate if you can point to me where is it mentioned.

If it's the API of the Windows platform lacking, can VB team specify or elaborate a little bit so people can go to MS forum and ask/talk about it?

We're trying to contribute by providing data/information for troubleshooting.

I am running VirtualBox 6.0.8 on Windows 10 1903 and just ran into the same problem: After activating all Hyper-V features, none of my guests (Debian 9 64 bit, Windows 7 32 bit) can be started. Even newly created machines (32 and 64 bit, 1 or 2 processors) crash immediately at start. The error windows shows this:

Für die virtuelle Maschine Windows 7 neu konnte keine neue Sitzung eröffnet werden.

Call to WHvSetupPartition failed: ERROR_SUCCESS (Last=0xc000000d/87) (VERR_NEM_VM_CREATE_FAILED).

Fehlercode:E_FAIL (0x80004005)
Komponente:ConsoleWrap
Interface:IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

I added the log file of the machine that caused this message.

None of the hints I found here in this thread helped me in any way.

Hyper-V itself is running fine. No problems with virtual machines directly created with Hyper-V.

@Clausimausi,

Enabling Hyper-V and/or any of the 'new' Windows functions that depend on Hyper-V and/or the exclusive use of VT-x, which you seem to have done, very effectively blocks the use if any other non-Microsoft virtualisation software because they deny essential access to VT-x. There appears to be only one effective 'option' at this time: Decide which Virtualisation platform you want to use exclusively and 'nuke' (completely purge/uninstall) the other one. Then watch the future development of VirtualBox (and Hyper-V) to see if/when programming solutions which satisfactorily address the current incompatibilities are found. This is, essentially, about 3rd-party software developers having to react; and find solutions for the arbitrary actions of Microsoft Windows 10 developers, who seem to have failed to consider/appreciate the wider impact of their decisions while implementing their own solution.

See the last post in this thread: viewtopic.php?f=1&t=62339#p452019 for an understanding of which Windows features are currently known to block the use of VirtualBox (and probably other virtualisation software). All of those have to be removed if from the system if you want to continue to use VirtualBox.

loyukfai wrote:Yes, I do not understand, and appreciate if you can point to me where is it mentioned.

Mentioned what? What does "it" refer to?

loyukfai wrote:If it's the API of the Windows platform lacking

Yes, as far as I know. There's no API to tell you what's using Hyper-V.

Getting a list of applications that use a particular feature of an OS can be tedious. I mean, think about it, can you tell me which app might be hooking into your sound card? Unless you do a reverse analysis of an application, and see which DLLs it might be calling, I can't think of another (easy) way...