I have a problem while creating a windows virtual machine.
This error is displayed:
VMware Workstation unrecoverable error: (vcpu-0)
Exception 0xc0000005 (access violation) has occurred.
A log file is available in "C:\Users\name\Documents\Virtual Machines\Windows_Server_2019\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.
I have several linux virtual machines and everything is working fine.
Nearly same effects for me. After upgrading yesterday to 16.2.0 build-18760230, my Windows VMs don't start or resume correctly anymore (access violation during boot). See windows-vmware-1.log.
The difference with the other posts is that while a Linux VM would resume and work fine at first, trying to pause it results in a similar crash as with Windows VMs. After the crash, the Linux VM needs to be restarted and it does restart fine, but when trying to pause it again, same crash. See linux-vmware-0.log.
Both access violations appear to be coming from the same place (ExceptionAddress 0x7ff6e4184984, base 0x00007ff6e4170000), i.e. same offset as in the initial report from Imperator_78.
I have since opened an incident ticket and am waiting for feedback from VMware.
(I can't really imagine that none of the developers noticed this bug, since it doesn't require any special installation. The main thing is Windows 11 compatible? 😕 )
The other common point I see in the logs besides Windows 11 seems to be Hyper-V (vmx IOPL_Init: Hyper-V detected by CPUID). I have colleagues that are doing fine with 16.2 but they don't have Hyper-V enabled. Maybe this setup is less common...
Same error here since the last update.
2021-11-18T18:31:37.913Z In(05) vcpu-0 [msg.log.error.unrecoverable] VMware Workstation unrecoverable error: (vcpu-0)
2021-11-18T18:31:37.913Z In(05)+ vcpu-0 Exception 0xc0000005 (access violation) has occurred.
Present error occurs only when multiple VM's are started in tabs of the same window. If each VM (guest) is opened in a separate window, the error does not appear.
It can therefore be assumed that it is a problem of resource sharing.
The error has not (yet) been fixed with version 16.2.1 - but at least the "Dark mode" works again 😉
VM is still silent on a service ticket about the issue 😉
For me this issue seems to present itself when my Desktop reboots and the VMs weren't shutdown or paused cleanly. I noticed that the virtual disk lock files were still present. I was able to clear the lock by powering on the VM to firmware and then shutting down the VM. Once the lock file was clear, the VMs were able to boot and run normally.
This is definitely an issue. VMware needs to fix this!
Because I need a Windows VM to do some work (using Pulse, Cisco Any Connect, etc.) mainly to RDP to other environments etc. CPU CORES/Horsepower is not critical as I'm RDP to the respective target systems.
What is working for me is if I set the setting of the CPU =1, CORES=1 in the 'Edit Settings' for the number of CPU's and CORE's... That'll at least start the VM so I can access remote system(s) etc.
I have a Surface Laptop Studio (i7, 32 GB, 2TB SSD) that came with Windows 11 Pre-installed. I only found this out AFTER installing all applications etc. otherwise I probably would have downgraded to Windows 10.
Not the best solution by far, but does allow the VM to 'run'
After a quarter of a year, there is still no solution on the part of VMware, let alone a solution approach!?!
My specially purchased support ticket with promised short response time is a joke.
Is the "VMware Workstation Pro" application still in the focus of the developers at all and part of the market strategic orientation?
Wanted to add that this error recently started for me after upgrading to 16.2.2.
Additionally, the workaround of opening the Microsoft Windows VM in a separate VMware Workstation window instead of in another tab in the same window, is preventing the issue for now.