"Transport (VMDB) error -14: Pipe connection has been broken." How to resolve this?

[justintime4vmwa]

I recently upgraded from VMWare Workstation 14 Pro to 15 Pro. I am receiving the following error message: "Transport (VMDB) error -14: Pipe connection has been broken." How do I resolve this?

[a_p_]

Have the VMs on the system been properly shut down (not suspended) before you upgraded to v15?

In case they were suspended, you may need to reset their power state to force a clean boot.

André

[justintime4vmwa]

No, they were not properly shut down before upgrading. I shut them down after the fact, tried booting them again, still the same issue.

[a_p_]

Is it the same for a newly created VM?

Does a new vmware.log file get created in the VM's folder when you try to power on an affected VM? If yes, please attach it to a reply post.

André

[justintime4vmwa]

I haven't tried creating a new VM, but I'll try that shortly. I have attached the log from today & yesterday.

[a_p_]

You've attached a hostd.log, but not the vmware.log from the VM's folder.

André

[justintime4vmwa]

No, the vmware.log is a month old (I'm not seeing anything newer) and I upgraded a couple days ago.

[justintime4vmwa]

I just tried spinning up a new VM. It has the same error.

[justintime4vmwa]

I solved the issue by disabling HyperV and running some commands.

[icssec]

I had this exact same issue on Mac OS Catalina, all the sudden I got this error.

Analyzing the vmware.log following lines  struck me:

                                                               FILE: File_CreateDirectoryHierarchyEx: Failure on '/tmp/vmware-[username]'. Error = 13

2019-12-12T13:45:34.119+01:00| mks| W115: MKSControlMgr: Unable to Create folder /tmp/vmware-[username]/mksctrl.

2019-12-12T13:45:34.119+01:00| mks| E105: PANIC: VERIFY bora/mks/main/mksControlMgr.c:454

2019-12-12T13:45:34.119+01:00| mks| W115:

2019-12-12T13:45:34.119+01:00| mks| W115+ The core dump limit is set to ZERO; no core dump should be expected

I created the /tmp/vmware-[username] folder myself and recursively changed the owner to [username].

This solved the issue for me! :smileycheck:

On windows I would expect another file location (probably not %temp% or %tmp% as these point to c:\Users\[username] which is completely owned by the [username]...

Let me know if this gives you enough inside to make it work for you.

[DrMohmX]

Hi,

Maybe you have already resolved this problem. But anyway, I will try to help you.

To resolve this problem you should simply turn off the Hyper Visor by using the command on CMD (Administartor) that I have attached below

bcdedit /set hypervisionlaunchtype off

And then just simply restart. I guess this solve your problem, If it's not solved yet.

[mradk]

This one worked for me.

PS C:\WINDOWS\system32>  bcdedit /set hypervisorlaunchtype off

The operation completed successfully.

[Mits2020]

I recently upgraded from VMWare Workstation 14 Pro to 15 Pro

If you upgraded from v14 to v15.0 or v15.5.2 and after that you upgraded the host to Win10 2004, the problem makes total sense.

But if you upgraded to v15.5.5 or v15.5.6, which are supposedly compatible to Hyper-V, this should not have happened. What am I missing here? What versions were the host and the guests?

[gotan]

On my side, I was stucked with same error On VMWARE Fusion 12.1 Pro with MacOS BigSur

• Same error message
• No explicit vmware.log 

After reading many forum topics, I've find somthing about /tmp dir

Solution was to allow writing for non root user on /tmp 

[gotan]

--

[siul72]

I have the same issue, none of the proposal solutions worked for me

[scotte30m3]

Thank you, your response fixed my issue on Catalina

I created the /tmp/vmware-[username] folder myself and recursively changed the owner to [username].

[CristianOlar]

After a recent Windows 10 update a few days ago, none of the suggestions here worked for me either but in reality, many were good for my particular situation in the sense that it really was Hyper-V that should have been disabled while the Windows Hypervisor Platform (in the WIndows 10 features -> search for "Turn Windows Features on or off" in the app searchbar) is enabled. Once that was all done, this error went away for me. However, it just looks like it became increasingly hard to disable Hyper-V in Windows 10.

After around ~10 hours of search I stumbled upon this complete guide https://thegeekpage.com/raw-mode-is-unavailable-courtesy-of-hyper-v/ for turning off Hyper-V. After doing almost all steps there, Hyper-V was finally stopped on my PC and vmware 16 resumed working. Yay 🙂 !

[chromacolor]

Hi scotte20m3

Where do you create this folder?

Thanks in advanced

[jrpentland78]

Not sure who may still be following this but there's more to just the not playing nice with Hyper-V.  Since my Hyper-V was turned off already, and I was still having intermittent issues with connectivity, I kept digging and found this:

https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-a...

Hope this helps.  I got that cleared up, and then had a random "Error -14 "Pipe has been broken" error, that just somehow resolved itself on it's own and suddenly my VM came up....I think that's almost more maddening than it continuing to be down.  I'm still going to research that error.

James