High CPU usage by vmnat.exe after upgrade to VMware® Workstation 17 Pro version 17.5.0 build-2258379

[Lippolt]

I just upgraded to VMware® Workstation 17 Pro version 17.5.0 build-22583795. Since then my system has a high processor load due to the file vmnat.exe (version from 10.10.2023, digitally signed by VMware). One processor core is 100% utilized.

I did not find anything in this direction in the release notes. What can be done about this?

With best regards from Hannover Germany,
Peter Lippolt

[foobar4711]

I can't seem to reproduce the issue with 17.5.1 at will anymore ...

[inetbas]

I upgraded also to 17.5.1 and still see that vmnat.exe remains top CPU consumer.

[Yedeluge8]

Upgraded to VMware Workstation 17 Pro version 17.5.1 today, this problem still occurs on my computer, AMD CPU.

[evrenbaycan]

They haven't fixed a **bleep** bug for months. I'm still on v17.0.2. Your notebook can melt if you forget to stop the vmnat.exe service 🙂

[Soskaarcu]

Thank you !

The solution still works with the version : 17.5.1 build-23298084 

exactly as the problem still is in there in this version too. 

I have tested two different machines,  but with the same version of Windows : Windows 10 1809 LTSC Enterprise x64 17763.5758

Furthermore ... as i had have to repatch the updated version i won't update VMWare anymore until this bug will persist.

[TarasII]

17.5.1 bug is still online

[chsc86]

Thanks. 17.5.1 Version: Exchanging VMNAT.exe to 17.0.2 Version worked like a charm.

Was a two week old installation on Windows 11, virtualizing another Windows 11 for Networking Purpose, at first there was the high cpu usage without service breakdowns only, but after some time, i just had to open a single ssl vpn (eG. Sophos or Barracuda) for breaking the service. Now everything is fine again

Odd thing for Vmware not having this critical bug fixed for almost 2 Versions now. 

Edit:

Process Failure Info (German) :

Name der fehlerhaften Anwendung: vmnat.exe, Version: 17.5.0.49595, Zeitstempel: 0x652515c0
Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.22621.3235, Zeitstempel: 0xb62363d8
Ausnahmecode: 0xc0000374
Fehleroffset: 0x000ed3af
ID des fehlerhaften Prozesses: 0x0x173C
Startzeit der fehlerhaften Anwendung: 0x0x1DA7EBA428DE2E8
Pfad der fehlerhaften Anwendung: C:\Windows\SysWOW64\vmnat.exe
Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\ntdll.dll
Berichtskennung: 7d611772-69df-4f36-8256-e810c20d4954
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

and

Name der fehlerhaften Anwendung: vmnat.exe, Version: 17.5.1.55451, Zeitstempel: 0x65caca7f
Name des fehlerhaften Moduls: vmnat.exe, Version: 17.5.1.55451, Zeitstempel: 0x65caca7f
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00012b4c
ID des fehlerhaften Prozesses: 0x0x5A30
Startzeit der fehlerhaften Anwendung: 0x0x1DA7EB8C61F1A5A
Pfad der fehlerhaften Anwendung: C:\Windows\SysWOW64\vmnat.exe
Pfad des fehlerhaften Moduls: C:\Windows\SysWOW64\vmnat.exe
Berichtskennung: 59b1ef59-e732-4ee2-9ab6-ad983c4289bb
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

[hyper_roo]

I've given up on VMWare Workstation entirely. Since I run Windows 11 Pro, I took my .vmdk and converted it to HyperV format, and I can honestly say, that I wish I had done this sooner. It runs faster than under VMWare and the hypervisor is more powerful (allows more than one VM to run simultaneously) than VMWare Player.  Incidentally, the inspiration came from a C't, a German computer magazine article in March 2024 edition.  It explains the steps to perform a smooth migration.

I think broadbom are hell bent on destroying the free/SMB tier of VMWare's customer base, and I think they are succeeding.

[MondoBass]

Can you please post the instructions for migrating to Windows 11?

[OKLakeGoer]

Here's the thing, it's not just the free version that has this issue.  All of my team have the paid Pro version and have to use this workaround.  

I agree, Broadcom seems to be taking the Oracle route with pricing/etc.  I'm thinking we'll be migrating away as well unless things improve.

[bbelcher]

All, 

I created a utility to address this problem temporarily. It basically sits in the system tray and checks the process usage of the vmware nat service every 20 sec. If high it restarts the service, if the vm workstation is not launched it shuts down the service and restarts the service if relaunched. 

It's been running on my machine for about 5 hours now. The interesting thing is the CPU spiked enough for 23 restarts of the vmware nat service. 

or do the math that's once every ~ 5 min. 

Now the restarts are fast and does not affect any network performance as far as I can tell. But I'm only streaming youtube off of a win 10 machine for testing.  The streaming does not stop i.e. buffered anyway. 

[hyper_roo]

I'll caveat my initial optimism and joy, by saying that HyperV and Cisco AnyConnect don't play nicely together. If you're someone who has to run AnyConnect VPN inside of your VM (and the VM is now running on HyperV) then you're in for some pain. Because HyperV uses RDP when the VM is in "Enhanced Mode". And why would you not want to run in Enhanced Mode (seamless mouse, screen res, etc. - it's like VMWare Tools that gives you better experience). So AnyConnect VPN terminates on ASA/FTD firewalls and by default the policy there is to block any VPN attempts that come from an RDP session. You guessed it.  You can't connect unless you do one of two things

1) Disable Enhanced Mode, connect, re-enable Enhanced Mode - pain in the butt

2) Configure the VPN profile on the headend to change the policy - that's tricky, when telling customers to disable that feature.

Despite this, I am still going to stick with HyperV.

The upgrade is roughly like this

1) Make a backup of your VM (e.g. copy the .vmdk somewhere safe)

2) Boot the VM and Uninstall VMWare Tools (HyperV doesn't need/use them)

3) If you're logged in with Windows Hello, then disable that

4) Connect an external disk/storage to the PC and passthrough the disk to the VM - you must be able to access this external disk, since it will contain the new HyperV using a conversion tool

5) Install disk2vhd (Sysinternal) inside the VM and run it.  

6) If you booted Windows using UEFI then select .VHDX format - otherwise choose the other one.

7) Select all the disks except for the external connected drive.  Then start the conversion

😎 You'll end up with a new disk drive file that can be booted in HyperV!!

9) Install HyperV. On your host, press Windows key, then type "windows-features" and run that.

10) Select all the HyperV options.  You host will need a reboot.

11) There are plenty of guides on how to use HyperV. It takes some getting used to, and VMWare is still prettier in my opinion.

[DavidChief]

Thanks for excellent solution. Difficult to find this thread because kept looking for NAT shutting down instead of high usage. VMware ships bug in both 17.5.0 and 17.5.1.

[adamitj]

I'm using version 17.5.1 build-23298084 on top of a Windows 11 Pro host. 

I noticed this happens only when I turn off/turn on or reboot the host. 

It seems that vmnat.exe is trying to access network services before the Windows Network Services becomes available. 

Since everytime I stop and start vmnat service it never came again to a high CPU usage, I just set the service to start delayed, and this solved the issue so far, without replacing files from older versions.

However, this may not be a full solution for everyone since there are reports on other forum posts saying that even restarting the service it will eventually begin to consume a full CPU core, but I'm monitoring my system to ensure it could be a final solution for this buggy issue.