dsesdg
Contributor
Contributor

Workstation 16.1.2 Pro, under Windows 11 host, Windows guest in VM crashes on startup

Jump to solution

This Reddit post sums up this issue well:  https://www.reddit.com/r/vmware/comments/ph590g/vm_does_not_start_on_workstation_1612_pro_windows/

Basically using Workstation Pro 16.1.2 on a Windows 11 host, if you create a Windows guest VM, and the host system has Hyper-V enabled in any form (in my case its present because I have WSL2 enabled in the host), and if you have more than one processor and/or one core per processor selected for the guest, the Windows guest VM crashes at boot:

VMware Workstation unrecoverable error: (vcpu-0)

Exception 0xc0000005 (access violation) has occurred.

A log file is available in "C:\Users\test\Documents\Virtual Machines\Windows 10 x64\vmware.log".

You can request support.

To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.

You can also run the "vm-support" script in the Workstation folder directly.

We will respond on the basis of your support entitlement.

In my case, I'm running this all on the released Windows 11 using an AMD Ryzen 5950x.  This same host configuration works without issue under Windows 10 (multiple processors, multiple threads per processor, etc.)  Also, if I disable and remove all instances of WSL2/Hyper-V on the Windows 11 host, then everything works fine in the guest with multiple threads enabled.

A similar issue appears to have been reported here back three months ago as well:  https://communities.vmware.com/t5/VMware-Workstation-Pro/VMWARE-16-1-2-on-Windows-11-host/m-p/285495...

It may be interesting to note that I also have several Linux guests running in the same host, and they work without issue (one processor, 32 threads per processor).  So this appears to be related only to Windows guest operation in this host configuration.  It doesn't matter if the guest installation is Windows 10 or Windows 11, the crash is the same.  

It'd be great to learn if VMware is working on this issue for an update soon...it's unfortunate that I can only run Windows guests using one core + one thread, on a 32 thread machine...

Thank you!

127 Replies
Supernatant
Contributor
Contributor

Yep, I had the same problem. It works on my Ryzen 4900 laptop, my Ryzen 3800X at home, but not my Ryzen 5800X at work on my Origin PC.

 

All 3 were Windows in place upgrades and not clean installs. I've had to use the BCD Edit work around, but it's garbage. Why does it work on 2 of my 3 machines, but not this one. This is the newest machine with the least time on the Windows install and the least amount of software installed. This is killing me having to turn that on and off to use Docker and VMWare.. . . . .... fix this VMWARE!

0 Kudos
Istolil
Contributor
Contributor

Intel Core i7, multi-core, running Windows 10 Pro Build 19043.

Updated Workstation Pro to 16.2.1, all my windows VMs now show this problem on startup except for 1, which is using identical virtual hardware specs to the others.

This isn't purely a Windows 11 problem.  Its a VMware 16.x problem.  I don't have the install executable for 16.1 so I can't even roll back and apparently Workstation Pro doesn't come with any support because my license shows no entitlement and I can't even figure out a way to GET entitlement.  

gkobler
Contributor
Contributor

Version 16.2.1 doesn't solve the problem. 😞

0 Kudos
redsolja
Contributor
Contributor

Downgrading VMware to 15.7 doesn't work either.

0 Kudos
fatcat-
Contributor
Contributor

I have a ticket open with VMWare for this and they blame MBEC:

It happens because the new systems have Mode Based Execution Control (MBEC) in the CPU.

No word yet on when this will actually be fixed.

 

0 Kudos
BillMITLL
Contributor
Contributor

 

<TLDR>
Windows 11 borks VMware Workstation 16.2.x Pro because of newly enabled Windows 11 security features.
The temporary workaround is to use Hyper-V or a really slow VMware VM until mommy and daddy stop fighting.
Both options suck and it will be very painful.
</TLDR>

 

 

For me, this appears to be a Windows 11 problem with VMware Workstation 16.2 Pro.
Here are a few data points from my instance worth considering.

  • Fresh install of Windows 11 Pro 21H2 22000.346 (TPM 2.0 w/Bitlocker Enabled)
  • VMWare Workstation 16 Pro 16.2.1 build-18811642
  • Framework Laptop using Intel i7-1185G7, 64Gb RAM, UEFI INSYDE BIOS 03.06 dated 2021.10.18
    (https://FRAME.WORK for really awesome laptops that are DIY maintainable - RIGHT TO REPAIR!)

 

VMware will not properly load any VM consistently.

Here are my steps to create a Windows 10 Pro 21H1 Virtual Machine on the above host:

Create custom VM

  • Hardware: Workstation 16.2.x
  • Installer disk image file: Guest OS Identifies ISO as Windows 10 and later x64
  • Firmware Type UEFI w/Secure BootProcessors 1, Cores per Processor 1, Total Processor Cores 1
  • Memory: 16384 Mb
  • Networking: NAT
  • I/O Controller: LSI Logic SAS
  • Disk Type NVMe
  • New VMDK 100Gb
    (Yes, this is a painful configuration performance wise, but I am trying to sidestep multi-core / hyper-threading / Hyper-V issues to test)

Error 1: Unable to open kernel device '\\.\VMCIDev\VMX': The operation completed successfully.
Solution Attempt: Close VMware, Edit Configuration File to turn VMCI to FALSE (vmci0.present = "FALSE"), Restart
Link: https://communities.vmware.com/t5/VMware-Workstation-Pro/Unable-to-open-kernel-device-quot-VMCIDev-V...

Start VM and install Windows 10, Reboot

 

Error 2: VMware Workstation unrecoverable error: (vcpu-0) Exception 0xc0000005 (access violation) has occurred.
Solution Attempt: Settings > Advanced > (Check) Disable side channel mitigations for Hyper-V enabled hosts
Result: VM Starts and continues Windows 10 setup. Reboot.

 

Error 3: Same as Error 2.
Solution Attempt: Restart VM.
Result: VM Starts and continues Windows 10 setup. (really stalls here for about 30 minutes 'finishing things up').
Completed setup, activated Windows and customized UI. Install VMware Tools and Reboot.

 

Error 4: Same as Error 2.
Solution Attempt: Restart VM.
Result: VM Starts. Ran Windows Update with (Advanced > Get additional Microsoft Updates) and downloaded standard updates as of 2021.11.13. Reboot.

 

Error 5: Same as Error 2.
Solution Attempt: Restart VM
Result: Windows update completed updates during boot. Windows Update wants more updates. Reboot.

 

Error 6: Same as Error 2.
Solution: Validated which Windows features were turned on/off in the physical host operating system (Windows 11)
Containers (off)
Device Lockdown (off)
Guarded Host (off)
Hyper-V (on, all)
Microsoft Defender Application Guard (off)
Virtual Machine Platform (off)
Windows Hypervisor Platform (on)
Windows Subsystem for Linux (off)

 

Error 7: Same as Error 2 without Boot
Solution: Changed VM Configuration
- Processors > Number of cores per processor: 4
Result: Will not boot. Same as Error 2, without Startup. Reverted setting.

 

Error 8: Same as Error 2 without Boot
Solution: Changed VM Configuration
- Processors > Number of processors: 4
Result: Will not boot. Same as Error 2, without Startup. Reverted setting.

Will boot with CPUs and Cores both set to 1 as per original configuration.
Windows Update no longer wants any updates. It took 45 minutes to get to this point after first boot.
Shutdown VM without error.

Started VM without error.
Shutdown VM without error.

I wanted to test out WSL2 and Virtual Machine Platform so I took the following steps:
Windows Features:
- Containers (on)
- Virtual Machine Platform (on)
- Windows Subsystem for Linux (on)

Rebooted physical host.

Started VM without error.
Shutdown VM without error.

On physical host started Powershell
PS > wsl --install -d Ubuntu

 

Error 9: WslRegisterDistribution failed with error: 0x800701bc Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel
Solution: Loaded new Linux Kernel
Link: https://docs.microsoft.com/en-us/windows/wsl/install-manual#step-4---download-the-linux-kernel-updat...
Link: https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi
Result: Successfully launched Ubuntu Kernel

Started VM without error while WSL2 Ubuntu shell was running.
Shutdown VM without error.

Shutdown VMware Professional
Left WSL2 Kernel Running

Created Hyper-V Virtual Machine with the following settings:
- Firmware: Boot from DVD Drive (of Windows 10 21H1 ISO)
- Security > Enable Secure Boot > Template: Microsoft Windows
- Security > Encryption Support > Enable Trusted Platform Module (checked)
- Security > Encryption Support > Encrypt state and virtual machine migration traffic (unchecked)
- Security > Security Policy > Enable Shielding (unchecked)
- Memory: 16384 Mb
- Memory > Enable Dynamic Memory (checked)
- Processor > Number of virtual processors: 4

Installed VM Windows 10 without Error (several times faster with 4 CPU cores) - No errors
Activated, Updated and Rebooted - No errors
Updated, Rebooted - No errors

 

Conclusion

In the thread and in other conversations, there have been a lot of thoughts about Hyper-V and WSM or other functions within the OS that may 'conflict' with VMware or another hypervisor. I can say that my testing with Hyper-V natively seems to work as advertised and VMware fails both before and after WSL2 is installed.  The solution above is to limit VMware based VMs to a single core single thread.

Unfortunately, Hyper-V is like stepping back 10+ years from a user perspective.  Microsoft really has done users no favors in making them use the archaic Hyper-V interface.  Local drive shares alone is horrid.

Microsoft seems to be flipping the switches to turn on many of the previously built security functionality which is now emphasizing the use of Hyper-V as a core part of the protection of the operating system.

Here is a good article on this, but there are many others:
https://www.techrepublic.com/article/windows-11-understanding-the-system-requirements-and-the-securi...

A little background on Windows 10 Hyper-V and Security:
https://www.techrepublic.com/article/how-virtualisation-is-changing-windows-application-security/

What I found is that I will have to suck it up and use Hyper-V until VMware fixes their product on Windows 11.

Hey at least it is on the same CPU instruction set. 🙂

0 Kudos
RedApple53
Contributor
Contributor

I had the same issue with  vcpu0 error after upgrading to both v16.2.0 and 16.2.1. reverted it back to v16.1.2 and all VMs started working perfectly fine. Host and Guests all win11. 

0 Kudos
C_Hurley_88
Contributor
Contributor

I'm not sure what's going on, I had W11 Pro as my Host OS working fine until I did a reinstall today, now all my VMs are gimped with 1 CPU otherwise nothing will run. the only thing I changed in my Desktop this week was upgrading from the 2070S to a 3080.

---------------

Updated Motherboard BIOS to latest version - Same issue

I've tried disabling Hyper-V - Same issue

Moved my VMs to my Laptop to test Intel 10750H on W11 latest patches with 16.2.1 - Works Perfect with the same VMs with multi-core!

Conclusion 

Most users with this issue have AMD-based CPUs so I wonder is this something to do with SVM or more specifically with AMD 3rd gen with high cores?  Since my Bare-Metal OS is not used for important work I'm thinking of doing a reinstall of W11 and making sure updated everything before installing VM-Workstation as I did this on my Laptop and I was actually prompted to take ownership of the VM, I noticed after installing W11 on my AMD Desktop it did not prompt me to take ownership of my VMs, Not sure if this is 100% a Windows issue or VMWare screwing up like with Darkmode on 16.1  

Comp specs

X570 MSI Tomahawk Wifi

AMD 5800x

32GB RAM 3200Mhz 

EVGA - 3080

  

0 Kudos
carvincent
Contributor
Contributor

Stesso problema anche a me .. installato ieri da key Windows 11 ... VMWare non va ... solo con un Core ... 

Purtroppo anche io ho un AMD con chipset 570 che già quello in se ha un botto di problemi.

0 Kudos
BrianBuresh
Contributor
Contributor

I have the same issue on Windows 11 with an 11th gen Intel i7. Machines will also report the CPU violation error when rebooting at times, randomly. I was able to mostly resolve the issue by setting a single CPU core on guests, but that's a bandaid. 

0 Kudos
cokebar
Contributor
Contributor

I have same issue on my NUC11 with i7-1165G7.  Disable Hyper-V makes all things fine.

On my laptop with an 8-gen core-i7, things are different. The vm can start-up with Hyper-V enabled but runs very slowly. Disable Hyper-V can fix the problem.

0 Kudos
C_Hurley_88
Contributor
Contributor

it seems to be hit and miss when disabling Hyper-v 

I've disabled Hyper-V / reinstalled Windows 11 and never enabled Hyper-V etc and still having the same issue, I had to reinstall Windows 10, and everything is working perfect, so MS seems to of changed something that has fully broken VM Pro 16 with the latest W11 build, I really wish VM were faster with patches.  

0 Kudos
swcasey
Contributor
Contributor

I currently have the same issue. I can get 32 bit guest OS systems to run but not 64 bit. the real interesting thing is I have three identical PC's running all are W11, Xeon processor. two of them I can run no issues 32 bit and 64 bit I only have the issue on the one.  

0 Kudos
Eric24
Contributor
Contributor

Same Issue: 1 cpu thread works.  more fails.  Hyper-V is NOT installed, but WSL2 is.  "Windows Hypervisor Platform" and "Virtual Machine Platform" are installed.

Windows 11

CPU: Intel Alder Lake 12900k

Mobo: Asus z690-e Motherboard - Default config (no overclocking)

 

 

0 Kudos
RomBog1
Contributor
Contributor

Confirm same issues. For me works if i Uninstall Hyper-V and DG/CG disable. "Windows Hypervisor Platform" and "Virtual Machine Platform" doesnt matter in which state. 

P.S. bcdedit /set hypervisorlaunchtype off not always works!

0 Kudos
jham512
Contributor
Contributor

This seems to have fixed it for me:

  1. Run “bcdedit /enum {current}”
  2. Note down the hypervisorlaunchtype in case this needs to be reverted
  3. Run “bcdedit /set hypervisorlaunchtype off” to disable hypervisor Close the command prompt after   executing the commands and restart the system.

Process to turn off virtualization-based Security:

Below steps can be followed to turn off virtualization-based Security for Windows 10 Home & Pro:

For Microsoft Windows 10 Pro & above:

  1. Edit group policy (gpedit)
  2. Go to Local Computer Policy > Computer Configuration > Administrative Templates > System
  3. Double Click on Device Guard on the right hand side to open.
  4. Double Click on "Turn On Virtualization Security" to open a new window
  5. It would be "Not Configured", Select "Disable" and click "Ok"
  6. Close the Group Policy Editor.
  7. Restart the system

Source:

https://kb.vmware.com/s/article/2146361#:~:text=For%20Microsoft%20Windows%2010%20Pro%20%26%20above%3...

0 Kudos
redsolja
Contributor
Contributor

This cannot be considered a fix, since you disable a core part of the security of the system and any other features that might be based on it, such as running WSLv2 or Docker.

In addition, the KB refers to Windows 10, before a specific update that was issued by VMware to make this turn-off of VBS not necessary.

This is a workaround, with many drawbacks.

0 Kudos
jham512
Contributor
Contributor

You can call it what you want, but my VM's boot now. Yes, you have to disable some virtualization security controls but until they issue a long-term solution this works for now.

CWmorin
Enthusiast
Enthusiast

Is there an update on this issue? I have the exact same issue -

Windows 11 completely updated

VMware Workstation 16.2.1 build-18811642

 

 

0 Kudos
BSoulMan
Contributor
Contributor

I can confirm that this 'TEMP FIX' (that jham512 referencesdoes work for me also.

Surface Laptop Studio running W11 (22000.348)

VMware Workstation 16.2.1.18811642

It'll get me by until VMware comes out with a REAL UPDATE/FIX etc.

 

 

0 Kudos