VMWare Workstation for Windows randomly loses copy/paste between host and VM

[netlib]

I am using VMWare Workstation (v14.1.3) for Windows on Windows 10 Pro x64. All the guests are Windows. When I start out I can copy/paste between the host and the guests. But after a while (and I am not sure when or why), I lose the ability to copy/paste between the host and some (but not all) of the guests.  The only thing that brings it back is to suspend all the active VMs, restart VMWare Workstation and resume the VMs. The VMWare Tools appears up to date (v10.2.5) on all the VMs.

Is this a known issue? Is anyone else experiencing this?

Some additional information: this only seems to affect Windows 10 VMs

[wila]

Hi,

Has been happening for as long as I can remember. So I have no hopes of this ever getting fixed.

There is however another workaround that fixes it.

Assuming you have a windows guest then you can create a batch file, eg. I call it "fix-guest-clipboard.cmd" and it has this content:

taskkill /F /IM vmtoolsd.exe
"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
pause "just ran C:\Program Files\VMware\VMware Tools\vmtoolsd.exe -n vmusr"

Then create a shortcut from the batch file and have that shortcut ready in a location you can click easily.

Run it, close the window (you can drop the pause line if you want) wait for 30 seconds or so and clipboard functionality is back.

Hope this helps,

--

Wil

[netlib]

Thanks for the tip.  Some more information: curiously this only seems to affect Windows 10 VMs.

I tried as you suggested. Incidentally, it never returns from the the second line (restarting vmtoolsd.exe).  Although I do eventually see two instances in TaskMgr: one for System one for currently logged in user.

However, it seems to only partially fix it: I can copy/paste from the VM to the Host, but I still cannot copy/paste from the Host to the VM.

[wila]

Hi,

Yes, that's correct. It does not return from the 2nd line, but it does start the process OK.

It's normal for there to be 2 vmtoolsd processes. One runs as SYSTEM (and does not get killed) and the other one runs under your user account.

It is the latter process that you are killing and replacing.

For me it has always been enough to fix the clipboard issues with just restarting that one process.

I never gave it much thought before as I just used this when somebody else suggested it as a workaround.

It would however be much cleaner to just restart the vmtoolsd service (then you restart both processes and it is done in the way that VMware designed it to work).

So I feel a bit silly for not realizing this earlier.

This can also be done from a script, but it needs to be elevated.

net stop vmtools
net start vmtools
pause "restart"

The "pause" isn't needed, but you can at least see it ran correctly.

Normally a script does not run with administrator privileges, but the commands above won't work without it. You can use "run as administrator" if you right click on it, or... create a short cut to the batch script. Then put a tick in the "run as administrator" option under "advanced" and it will do so on double clicking the shortcut.

As always with more power comes more responsibility.

An alternative is to go to the Windows task manager, open the services tab page, locate the vmtools entry and use the restart option.

--

Wil

[martijntonies]

This doesn't cut it for me.

I've got a W10 host, several Windows guests. W7 as a guest works fine, can copy/paste text without problems. Fails with a W10 guest.

Tried several things > no clue why it's failing.

[wila]

Hi,

It doesn't cut it for me either... it's a workaround.

I would much rather see that VMware resolved this, but as it has been a problem for over a decade, I am not having high hopes on it getting resolved.

BTW, the first script I posted has better results for me than the second one with net start / net stop.

--

Wil