Cumulative update for Windows 10 1703 broke Virtualbox VT-x recognition

[edwaldner]

On 2017-0809 around 1700EDT I upgraded my laptop with a security update for Windows 10 (​https://support.microsoft.com/en-us/help/4034674/windows-10-update-kb4034674) and a security update for Adobe Flash player for windows 10 (​https://support.microsoft.com/en-us/help/4034662/security-update-for-adobe-flash-player-aug-08-2017).

The following morning I attempted to power up my VM that has been running without major hiccups since mid July and got the following failure code:

VT-x is not available (VERR_VMX_NO_VMX).

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

Online searches revealed that this type of problem has been encountered before.

1. ​https://superuser.com/questions/1153470/vt-x-is-not-available-but-is-enabled-in-bios

I tried dism.exe /Online /Disable-Feature:Microsoft-Hyper-V and rebooted but problem persisted.

2. ​https://stackoverflow.com/questions/5482223/vt-x-is-not-available-when-i-start-my-virtual-machine

I reduced my VM's memory footprint below 4096 but when I powered it up I got a Win10 BSOD

3. ​https://forums.virtualbox.org/viewtopic.php?f=6&t=58820

I ran c:\Program Files\Oracle\VirtualBox>VBoxManage.exe modifyvm CentOS-Adva-Dev --longmode off

without any noticable effect on this problem.

I confirmed my laptop's virtualization support is enabled in the bios settings.

I attempted to create another VM and noticed that my only VM guest types are 32 bit.

I attempted to run an installation repair to my VirtualBox 5.1.26 installation without any success.

I have not tried:

1. Uninstall and reinstall VirtualBox application on my host - I have no reason to believe that this will resolve the issue

2. Rolling back the Windows security updates - this action probably carries more risk than reward.

[edwaldner]

VBox.log from my environment

[edwaldner]

Hardening log

[Frank Mehnert]

Same as #16997 but I closed the other ticket because this ticket contains more information.

[Klaus Espenlaub]

Is this with some "feature limited" Windows 10 version which doesn't include Hyper-V as a feature? Then you can't disable it the usual way (because it's logically not there), but still the kernel might be running in the hypervisor, blocking VirtualBox from using VT-x.

Try running (in an admin cmd.exe): bcdedit /set hypervisorlaunchtype off

After that restart Windows and things should work again. Could be that some Windows update was accidentally losing this setting, which I assume you had in place before.

[Socratis]

Besides making 110% sure that Hyper-V is disabled in the settings, you might want to ​make sure that Fast Boot is disabled and do a cold boot (i.e. shut down the host for a minute or two). You also must make sure that nothing else is using Hyper-V, things like antivirus, debuggers, emulators, etc. Check out the article ​Diagnosing VirtualBox Hardening Issues to get some ideas...

[Frank Mehnert]

Btw, I'm running the exact same Windows 10 build locally without any problem (VBox uses VT-x) so it cannot be a general problem of this Windows 10 build.

[edwaldner]

Thanks for your responses so far. I am in the same boat as before. To answer some questions:

1. I am running Windows 10 Enterprise v1703 os.build 15063.540 on a Dell Latitude 5580. I'm thinking this is not a hardware related issue nor a bios related issue since both are the same as they were before my last Windows 10 major update. Virtual box was running without any problems before the windows 10 update last week.

2. I tried the bcedit /set hypervisorlaunchtype off from an admin enabled cmd window and restarted my laptop - no effect, same issue.

3. I tried uninstalling virtual box and reinstalling from a newly downloaded package installer - no effect, same issue.

4. I have not done anything to enable or disable Fast Boot, but my laptop is shutdown each evening and restarted anywhere from 1 to 12 hours later.

5. My laptop is currently using the same antivirus, and any other program that may have been using Hyper-V as it was prior to the Windows 10 upgrade event last week. For reference, the laptop is using Windows Defender packaged with Windows 10 and Bitlocker is enabled (although I'm not sure to what extent Bitlocker is Hyper-V dependent)

6. I looked thru the hardening post. Aside from shutting down the windows defender AV, I've gone thru the steps without result. This is a corporate machine and I have no control over disabling antivirus.

I can appreciate that you are not experiencing the same issue as I am and it is very likely that this may be a configuration/setup difference that is being highlighted by the Windows 10 update (or maybe the Windows 10 update timing is purely coincidental with the onset of this issue), however I don't have the expertise in trying other things beyond what I've outlined above.

Please let me know if you have other things to try.

[Klaus Espenlaub]

Relatively quick try: check in the BIOS/UEFI setup if you have trusted execution enabled. If it is: disable it. Blocks the availability of VT-x.

A more elaborate try at finding out who's to blame:

Since Windows is a rather hostile environment (Hyper-V may or may not be disabled, for whatever reason) and detecting the availability of VT-x is extremely difficult (don't trust the web pages which give easy instructions for detecting if VT-x is enabled by the BIOS, by checking the CPUID features - which from my experience is totally unreliable, it just reflects if the CPU has the feature or not, but will not change if it's disabled).

Do you happen to have some Linux Live CD/DVD at hand which reasonably recent? A Ubuntu install CD should do the trick, too. No need to install anything, just use the Live CD to boot your system. In the Ubuntu case select "Try Ubuntu without installing".

Once the Linux Live environment is up, start a terminal window. In the terminal, enter "sudo modprobe kvm-intel". Likely you get a failure (something about "could no insert"), if that's the case run the "dmesg" command. In the last lines of its output you'll get some "kvm: ..." information. Please provide those. If you don't get a failure then your CPU has VT-x properly enabled, and we're back in the situation that Windows/Hyper-V/some AV software/... uses VT-x, without an easy way to find out who's to blame.

[edwaldner]

Thanks Klaus. This laptop has three virtualization support areas that can be enabled or disabled via checkbox.

1. Enable Intel Virtualization Technology (checked - enabled).
2. Enable VT for Direct I/O (checked - enabled) -- there is a note in there about requiring this for running Trusted Execution.
3. Trusted Execution (unchecked - disabled).

I can try disabling VT for Direct I/O to see if that makes a difference.

I'll also try booting from a live linux image, run the modprobe for kvm-intel and see if anything funky comes up. Will post results as soon as I'm done.

[edwaldner]

The VT for Direct I/O option was cleared but had no effect. Virtualbox was still unable to create any 64bit VMs and my VM instance was still showing up as Ubuntu 32bit. I will try the live boot option tonight once I get a live boot USB prepared.

[edwaldner]

While I was not able to boot a liveboot image on my laptop, I was made aware by one of my co-workers of a similar issue with VMWare and Windows 10. They have posted a knowledge base article on the problem that apparently revolves around Credential Guard/Device Guard - a feature in Windows 10 that seems to use Virtualization Based Security and interferes with other virtualization platforms.

​https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2146361

I performed step 1, skipped step 2 (Hyper V already disabled on my laptop), 3, 4, 5 and 6. After reboot I was asked to confirm the opt-out request for both Device Guard and Virtualization Based Security.

After windows finished the boot process, I started virtualbox and had the option to change my VM to a Ubuntu 64bit type (it defaulted to Ubuntu 32bit), after which my VM started up without problems.

Provided Microsoft leaves things be, this should be a good enough workaround to close this issue.

[edwaldner]

Just in case the VMWare KB article goes away:

To disable Device Guard or Credential Guard:

1. Disable the group policy setting that was used to enable Credential Guard.
   1. On the host operating system, click Start > Run, type gpedit.msc, and click Ok. The Local group Policy Editor opens.
   2. Go to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security.
   3. Select Disabled.

2. Go to Control Panel > Uninstall a Program > Turn Windows features on or off to turn off Hyper-V.
3. Select Do not restart.
4. Delete the related EFI variables by launching a command prompt on the host machine using an Administrator account and run these commands:

mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

Note: Ensure X is an unused drive, else change to another drive.

5. Restart the host.
6. Accept the prompt on the boot screen to disable Device Guard or Credential Guard.

[edwaldner]

Issue occured again after latest Windows 10 update last week. Microsoft seems to be very determined to stop its users from running 64 bit virtual machines.

The group policy settings I had in place a few weeks ago were retained across the Windows 10 update as were the Hyper-V settings.

Running step 4 commands at an admin elevated cmd prompt and rebooting prompted me to reconfirm the credential guard opt-out and virtualization ?? opt-out (F3 to both confirmation dialogs). Following reboot, VM started ok.