AutoStart VMs have no display in VMware Workstation Pro 17

[RichardDale]

II have successfully configured three VMs to auto-start upon reboot, with the VMware Autostart Service using the same account/login credentials.

When using the VMware Workstation console, all I see is a blank screen, even though the guest is running fine:

I can perform any of the commands (Restart Guest etc.) but there is still no display.

If, however, I "Shut Down Guest" then power it on, then the display returns.

Not being able to see an auto-started Guest is a big (!) issue.

Environment: Windows 11 host, Build 17.0.0.build-20800274

[somevmwarecstmr]

I'm seeing the same thing - blank screen after setting up autostart in Workstation Pro 17.  

In case this could help the devs pinpoint the issue:

I created the vms (one windows 10, the other ubuntu 20.04) as normal vms, then enabled the autostart service WITHOUT setting the service to my local account (was running as the default local system account). 

At this point, the virtual machines would autostart as desired and work fine, but when I went into vmware workstation pro 17, the virtual machines were displayed as not running.  

After realizing that I forgot to set the vmware autostart service to login using my account user, I later changed the service to use my normal user per the knowledgebase (https://docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-44497201-A4AC-4867-BEE7-1BDC7641E66C.html). 

The virtual machines now show as running in the vmware workstaiton pro application.

This is when I found the blank console screens within vmware workstation 17 pro, yet the virtual machines seem to be running just fine (I can RDP and ssh to the machines).

Host is Windows 10 Pro 22h2 19045.2364.

[Cmaples]

Same setup/situation here, is this going to be addressed or is this by design? 

[somevmwarecstmr]

Adding more information to the post above...

 

The blank screen of the autostarted VMs (started from the autostart service configured to run as the user I'm logging in as...) seems to be temporarily resolvable by powering off the vm and starting it again from the vmware workstation application.  If I do this, the console appears again.  If I reboot the computer and let the autostart service start the vm, then log in as my user and open vmware workstation, the blank screen is back until I manually reboot the virtual machine.  This is 100% reproducible on my system.

[RichardDale]

Can confirm here - a restart of the VM (while logged in) does restore the screen properly but clearly this defeats the purpose of an auto-started VM in the first place.

 

[RichardDale]

Further to my original message, a Knowledge base article has been posted which bascailly says that Window restricts any video rendering from "session 0".

https://kb.vmware.com/s/article/89855

A workaround is suspend then resume the guest (once logged in).

So, this will never be solved due to Windows limitations.

 

 

[robnicholsonmalt]

>So, this will never be solved due to Windows limitations.

True but it would be "nice" if VMware Workstation had a feature to take over the auto-started VM. If it's running as system, it has to suspend the VM using that account and then resume in the console.

[wila]

---

 wrote:

Further to my original message, a Knowledge base article has been posted which bascailly says that Window restricts any video rendering from "session 0".

https://kb.vmware.com/s/article/89855

A workaround is suspend then resume the guest (once logged in).

So, this will never be solved due to Windows limitations.

---

Bingo! It is indeed because of the session 0 restriction. You're running a VM before the user has logged into windows and as such it can never get access to the desktop.

This is also exactly the workaround that Vimarun employs in order to not have this annoying issue. Vimarun automates the suspend/resume on login in case you want to run the VM in the foreground, so you don't really notice it much.

The one other remark I haven't seen mentioned in this thread is that the "good old" shared Virtual Machines feature did not have this particular issue. The reason is that it all worked completely different, but it is interesting nonetheless.

--
Wil

[RichardDale]

For my well-protected system, I use:

1. Autologon:

https://learn.microsoft.com/en-us/sysinternals/downloads/autologon

2. Have created a batch file that has a shortcut in "startup" (Win-R shell:startup)

cd "C:\Program Files (x86)\VMware\VMware Workstation"
vmrun -T ws start "d:\VMs\vm1.vmx"
timeout 5 > nul
vmrun -T ws start "d:\VMs\vm2.vmx"

 

[VMware Community Member]

Until VMware actually fixes the built-in autostart feature, this is the way. After wasting so much time with permissions and reboot tests, this script method just works flawlessly.

[Edisson Garcia]

Thanks a lot Richard. This worked fine for me! 

[kesparlat]

This issue never happened on previous Workstation versions. I used to "autostart" my VMs by using the "shared VMs" feature.  That means that this can be fixed by VMware and it's not a Microsoft issue.

[RDPetruska]

The shared VMs feature was implemented in a completely different way than the current 'autostart' feature.

[Jim_]

If you RDP into the VM, it displays appropriately.  My guess is the headless nature of the autostarted machine is causing the issue. 

[c-real]

This KB is like VMware spitting in people's face.

There's a reason one might want to have an autostart for VMs.
There's also a reason why someone might want to have a *working* console for a VM in case something goes sideways.

How come HyperV also offers autostart for VMs without need to mess with service configuration AND on top of that, the console works just fine? If it's a system limitation/security thing, HyperV gets around that somehow.

I do realize this isn't something that's sitting on the top of priority list to fix by devs, but come on... 200$ for a software that's a hypervisor that doesn't have one of the basic functionalities of a hypervisor?

What would the business say if some admin logged into a vCenter after a power failure in a DC just to see that maybe thousands of machines need to be suspended and resumed, because the console doesn't work? That definitely sounds like fun.

VMware is starting to sound like a Todd Howard stating "it just works". Though this time it's the other way around.

[User489234]

Interestingly, this doesn't appear to be an issue for virtual machines that were created from physical machines using VMWare's Converter tool. I can set these to autostart and when I view them through VMWare Workstation 17 Pro, the machine's screen appears and I can just log right in.

Maybe creating a VM from an OS installation (i.e. from scratch) has something to do with it. I agree that it's an annoying issue.