Memory leak with shared folders enabled?

[73blazer]

I seem to be experiencing a memory leak.

I've had the same setup for about a year, v12 (12.5.7 currently) running on windows 10 pro x64. I have three guests, one windows 10, one unbuntu 16 one bsd.

They've all run happily for quite some time, until, I enabled shared folders on the Unbuntu guest.

Now, when I run that guest and leave it up, memory on the host ticks away slowly over 2-3  days (there's 64gb on this host) and will slow up the host once it gets down to nothing.

I left that unbuntu guest off for a  day last week during the holiday  when I could and no loss of memory occurred. Turn that guest on... watch the host memory tick away .1gb every min or so, until you've lost it all. I'm quite certain it's that ubuntu guest with shared folders enabled and being used. I never lost memory with that guest on for months, until I enabled and used the shared folders.

Is there some known issue with shared folders? Anything I can try?

[bonnie201110141]

When memory leak occurs, can you please check which process is eating most memory via Windows task manager or Windows Process Explorer? If it is caused by shared folder, vmware-vmx should be occupying most memory. Thanks!

[73blazer]

Well, that's the thing. Windows, doesn't show any process using that much. If I got to taskmgr and pick processes and sort on memory, nothing is really huge and I can add all those up and and it's nowhere near 64gb. But the overall free shows all in use and 0 free and it actually starts paging and slowing the whole thing down to a crawl. If I stop vmware and shut it down completely (all three guests and VMware itself)  at that point, I don't get the memory back. I can only reboot.

What I do know is, if I start vmware and the other two guests and leave it running for a day, it's perfectly fine. start that 3rd ubuntu guest with the shared folder and the memory slowly starts ticking away. And it all started (we have very strict change control and I'm the only one who really goes on this server) when we turned on shared folders on that ubuntu guest. We had that guest running for months without any memory loss until we turned on shared folders for it. Nothing else changed, that was the change this started on .

I need to get a better memory analyzing tool for windows, the default one seems limited.

[bonnie201110141]

Yes, please get a better memory analyzing tool such as VMMap.

[73blazer · Accepted solution]

I found the source of the problem. Using various memory tools I could see the used memory was stuck in non-paged pool area of a process that I traced back to the network card driver.

I had to use alot of different memory tools. The built in Windows task/resource just showed all the memory gone, but if you went to details, no process or item was taking up anything much even if you turned on show all memory columns/items in the details section.

ANd it only happens if you turn on shared networking in VMware between the guest and host and are using bridged network mode (not nat) The more activity in the shared folder from the guest end, the quicker the host would lose memory.

So.....It was the network card driver.

I was on a "killer" nic card and once I updated the driver to the latest, the problem went away. I had to get the driver from the killernetworking site directly as the machine manufactuer website only had the driver that was already on it which was old.

My board also had another card in it, an intel network card, so I switched off the killer onto that card and also there is no memory leak using that card. Killer is just QOS anyway, we have routers for that. I left it on the Intel nic.

[bonnie201110141]

Glad to know you fixed the issue. The issue is weird to me because shared folder does not use network. Actually if you disable host network, shared folder can still work well.

[73blazer]

YOu can remove the network cable, but under the covers it's still using the nic for the underlying tcpip communication. WHile the traffic never leaves the nic, remove the nic itself and you won't have a shared folder, it'll be de-highlighted.

[dariusd]

Sorry, but that's simply incorrect.

VMware Shared Folders does not depend on TCP/IP nor on network connectivity.  It can work quite happily in a VM with no NIC at all.  It has its own protocol over its own "back channel" that is independent of networking devices.  Shared Folders is actually quite handy for getting files into a VM that's been deliberately isolated from any networks.

Some versions of Windows, when running as a guest OS in the VM, have an interesting bug where if you configure the VM with a NIC, tell Windows that the virtual network is "Private", and then disconnect the NIC, Windows Explorer no longer shows the Shared Folders entry, instead saying "This computer is not connected to a network.  Click to connect...".  That's just a Windows UI bug though... even in this state, the shared folders should still be accessible by entering "\\vmware-host" into the location bar in Explorer.

If your "Shared Folders" are truly using the network, you're probably somehow using Windows File and Print (SMB) sharing to communicate with the host, instead of the Shared Features folder built in to Workstation.

Cheers,

--

Darius

[73blazer]

POssibly. I'm no expert in how it works.

However, it is using real VMware shared folders and the nic driver was the cause of the memory leak. So, somewhere, vmware shared folders are seeing it. Mabey it works fine without and if it's there uses it for something. Is there a machine without any nic anymore? I doubt it. Not sure that's even a testable scenario as most boards have one built in with no way to remove it. My guess is, it's using it in some manner. I don't know.

I do know, turning on VMware shared folders  (right click vm guest in vmware->settings->options->shared folders set to enabled) started a memory leak because I could restart the VM without it and no leak, turn it back on, leak......and the nic driver update fixed it. It is using it in some form.Also, it only happened if using the guest in bridged network mode. shared folder in nat mode worked without issue.

It's a share presented as a disk to the ububtu guest.

root@ubuntu:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

udev            2.0G     0  2.0G   0% /dev

tmpfs           394M  6.2M  388M   2% /run

/dev/sda1       7.0G  6.3G  346M  95% /

tmpfs           2.0G  252K  2.0G   1% /dev/shm

tmpfs           5.0M  4.0K  5.0M   1% /run/lock

tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup

vmhgfs-fuse     239G  168G   72G  71% /mnt/hgfs

tmpfs           394M   48K  394M   1% /run/user/1000

The same issue,or very close to it, was reported by a user of virtual box with the same basic thing, internal shared folders. WHen he turned it on, he got a leak. He also paired that down to his network card driver. Updated it, fixed his issue.