Hello, I got a problem after upgrade to Windows Insider Preview 1903 18362.30 x64 on host machine.
CPU : I5-8400
RAM : 16G
Host OS : Windows 10 1903 x64 18362.30 (Latest WIP)
VMWare Version : 15.0.4 build-12990004
Other Status :
"bcdedit /set hypervisorlaunchtype OFF" (Means that Windows Native hypervisor already turned off)
"Memory integrity guard OFF"
"Credential Guard OFF"
Before I upgraded to Windows Insider Preview 18362.30, I was using Windows 10 RS5 x64 as a host operating system.
I could run any VM guest machine without any problem.
But, after I upgrade to Windows 10 1903, I cannot run any VM guest.
Guest screen only shows a black screen, and nothing happens.
What I can do is just rebooting machine. Cannot terminate vmware-vmx.exe process.
Anybody has same issue like this? And if anybody has solution it will be very thankful.
I agree here. I was told by a co-worker about updating the NVidia driver and when i did, all my VMs are functioning again. Still should have VMWare look at the issue and fix it but updating the drivers worked perfectly for me.
Is this issue already fix by Microsoft or VMware? Because I am still having this issue. Reinstalling Nvidia driver fixes the issue but after the host reboots, the issue comes again.
Here is the original solution - work around given by someone else back in 2013 and I have confirmed that it works with windows 10 1903 (pre-releaase version) and vmware
original postis here>>>>> All VMs Start with Black Screen
Yes...sort of found a workaround that gets past the problem. Wish VMware would acknowledge the underlying problem or provide a fix.
I have found that no matter my VM settings, I have problems if there are no errors with the VM configuration. The VM starts and the guest OS boots normally, but the screen remains black and the task needs to be terminated.
If however, I configure the VM such that there is some sort of configuration error (non-existent device, CD-Rom mapped to missing ISO, etc...) that Player throws a warning dialog about the configuration problem on VM boot and whatever that does to the video it is enough to get the VM to boot correctly with the display active. So as my workaround I added a floppy drive to all the VM's (which doesn't really exist on the host) and that is enough to generate a "Cannot connect the virtual device floppy0 because no corresponding device is available on the host." dialog on start that you have to click Yes on (to prevent Player from "fixing" the config issue) and that works around the video problem for all of my VM's. (XP, 7Ultimate, 😎
Hope this helps you out.
Thank you tom and I hope this helps people out!
Ok I was able to relaunch my virtual machines using the fake iso boot..... but I have to restart my machine after each hang. Then indeed the windows vms would launch and i would save their state.
As long as they are in a saved state resume works ok.
I didnt try with linux VM's though.
Update: Workstation Pro 15.1.0 update appears to have resolved outstanding drag / drop issue .... still have to fingers crossed that Windows Sandbox and VMWare can finally coexist as both are point in time executions and do not need to run in the background i.e. can run Sandbox or VMWare but not necessarily both but both can be installed at same which is not currently possible due to Hyper-V
Without doing any exhaustive testing for those just needing to get something scrappy working here is what worked for me:
After applying the Microsoft April update to 1903 : 18362.86 and updating to the latest Intel network drivers
within VMWare Workstation Pro on initially a test VM:
Disconnect CD/DVD and Audio so they don't connect on boot of VM
Deleted the VMWare provided printer ( personally never use now that all printing can go via the network )
Note down the folder for the VM typically from the primary disk location.
Close VMWare Workstation Pro and edit the VM's .vmx file and changed any E1000 network drivers to vmxnet3.
e.g. ethernet0.virtualDev = "vmxnet3"
if there isn't a line for the ethernet0.virtualDev ( or whichever net adapter you have e.g. ethernet1 ) .. add it so it doesn't default to the E1000 driver
Restart VMWare workstation and in my case then worked. Tested with combinations of VM's from complex disk configurations and various recent OS and all successful. Rebooted host and still all working.
I'm not a VMware employee, but you guys who have this problem have to know this.
Windows 1903 is STILL beta, is not distributed for general availability.
Usually software company does not have any responsibility to react software issues in beta operating system environment.
If anybody who really wants to use VMware, roll back to Windows 1809, or wait for next VMware update.
I have no idea when VMware rolls out next update, but I only know that Windows 1903 general availability date will be late May.
You may assume that VMware next update will be rolling out when Windows 1903 is available.
I can confirm the same issue occurs using the Release MSDN Windows 10 1903 client install
Any eta on the VMWare update for 15.0.4 to resolve this issue?
1903 is the May Feature release, isn't it? That's not beta (well, not beta as far as Microsoft is concerned). I'm getting the notification to reboot to install it now, and I'm not running any insider build/configuration on my main workhorse machine ... I'm not even on the Targeted channel.
Fortunately I've made group policy edits that prevent a forced reboot on update, but I know I'm going to have to reboot at some point. If that breaks VMWare, I will be truly and painfully f***ed.
I'm in the same boat but I've been having to reboot my host windows multiple times a day for to guests locking up and nothing can be done.
I've started to migrate all our offices work to virtual box, I not a huge fan but right now it's causing major issue for us.
Yeh 1903 is rolling out now, if you have a USB drive/stick installed, you may not get the offer as as I heard there was an issue where 1903 after installation remapped the drive letters of USB drives to one leter higher or similar.
I installed via an ISO from MSDN last week and had a few issues like biometrics not working for the Razer Stargazer and MS' own biometic fingerpint BT keybaord <sigh>.