If the Host is rebooted, Workstation will not start. To get it back I have to Uninstall VMware Workstation, Reboot, Install VMware Workstation, Reboot, then i can start and stop the guest without issue. As soon as the Host is rebooted again, the guest will not start with the message VMware Workstation has stopped working / I've used this process with both V12 and V14 of Workstation
Anybody else have this problem?
Would you please use VMware Workstation 14 to reproduce the issue and upload the vmware-ui.log? Thanks very much. Steps:
1) Launch VMware Workstation and open "Help -- About Workstation" and identify the location of vmware-ui-xxxx.log, the default location should be C:\Users\{user}\AppData\Local\Temp\vmware-vmware\vmware-ui-xxxx.log
2) Try to power on a guest to reproduce the "VMware Workstation stop working" issue.
3) Attache the vmware-ui-xxxx.log.
Since I'm having the same problem, here's what happens: after you start the software, no window appears. Instead it runs in the background, consuming 25% CPU capacity (one core) and 2.8 MB of RAM. I had to kill the task. After that there won't be a file or folder with "vmware" in the name in \temp. The four services are running. The event record doesn't show anything.
Thank you,
I'll try and recreate the problem and capture the associated Log File.
The log files are attached.
One is when Workstation fails to start following a reboot of the host.
The other is after I uninstalled Workstation
Rebooted
Installed Workstation
Rebooted
Then brought up Workstation successfully.
Thank you,
mark seitzer
Thanks for your log files, just want to confirm that when you hit the stop working issue? when launch Workstation UI or when power on a VM?
The failure happens when launching Workstation.
The Guest is encrypted, meaning the dialog to enter the password does not come up before the failure.
-mark seitzer
Any news? Fall Creators Update is out since a while and Workstation not working at all is not funny.
Present we can not reproduce the issue on Windows10 1709 host. And the bad behavior you described seems different from "Marks2017", you said that there is no related log files generated, so maybe the process is dead-locked. It is very helpful if you can use windbg to produce crash dump for analysising.
Detail step:
Install Windbg from: https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit (find Get (WinDbg) as part of Windows 8.1 SDK), launch the sdksetup.exe and install the "Debugging tools for Windows" component.
After reproduced the issue, do the following steps:
Hi, mark:
From the logs you provided, we have not found any useful clues. And would you please help us to collect more information using Debug Diagnostic Tool? The tools can be download at the following URL: https://www.microsoft.com/en-us/download/details.aspx?id=49924
Detail steps:
The dumps are located by default in "C:\Program Files\DebugDiag\Logs\Crash rule for all IIS_COM+ related processes" or in "C:\Program Files\DebugDiag\Logs\Rule_Name".