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

[StefanHback]

Hi!

Windows reports the attached file (file/files in the vmnat.zip file) as a trojan (Trojan:Win32/Cloxer)??

I have the same NAT problem after upgrade to 17.5. vmnat.exe running high on one cpu core/process ..

...

[johnatansmith]

No, the file posted at the top is totally safe. It is code-signed by VMWare - nobody can do that unless they have VMWare's private key. So the file legitimately came from VMWare.

As for your report, check MD5 hash of the file. It should be 240EC1879073D0D70DF7150A5927580D. If hash matches then you just have false alarm. If hash does not match, then you have problems much more serious than misbehaving NAT - someone is tampering files that you download from internet on-the-fly.

[ralish]

Frustrating to see this was both reported during the beta and despite the numerous replies in this thread still hasn't had a response.

For anyone from VMware who can assist with getting this resolved, this is a stack trace of the thread on which the high CPU activity occurs, in which it appears to be stuck in an infinite loop:

ntoskrnl.exe!KiSwapContext+0x76
ntoskrnl.exe!KiSwapThread+0xab5
ntoskrnl.exe!KiCommitThreadWait+0x137
ntoskrnl.exe!KeWaitForSingleObject+0x256
ntoskrnl.exe!KiSchedulerApc+0x23e
ntoskrnl.exe!KiDeliverApc+0x2f6
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x2b
ntoskrnl.exe!ExReleaseResourceAndLeaveCriticalRegion+0xf1
win32kbase.sys!UserSessionSwitchLeaveCrit+0x137
win32kfull.sys!NtUserMsgWaitForMultipleObjectsEx+0x529
win32k.sys!NtUserMsgWaitForMultipleObjectsEx+0x20
ntoskrnl.exe!KiSystemServiceCopyEnd+0x25
wow64win.dll!NtUserMsgWaitForMultipleObjectsEx+0x14
wow64win.dll!whNtUserMsgWaitForMultipleObjectsEx+0x90
wow64.dll!Wow64SystemServiceEx+0x164
wow64cpu.dll!ServiceNoTurbo+0xb
wow64cpu.dll!BTCpuSimulate+0xbb5
wow64.dll!RunCpuSimulation+0xd
wow64.dll!Wow64LdrpInitialize+0x12d
ntdll.dll!_LdrpInitialize+0xe7
ntdll.dll!LdrpInitializeInternal+0x6b
ntdll.dll!LdrInitializeThunk+0xe
win32u.dll!_NtUserMsgWaitForMultipleObjectsEx@20+0xc
USER32.dll!MsgWaitForMultipleObjectsEx+0x51
USER32.dll!_MsgWaitForMultipleObjects@20+0x1f
vmnat.exe+0x3348
vmnat.exe+0x15391
ntdll.dll!___RtlUserThreadStart@8+0x2b
ntdll.dll!__RtlUserThreadStart@8+0x1b

Taken from VMware Workstation Pro v17.5.0 on Windows 11 23H2.

[emerson67]

Same issue on Windows 10 22H2 host

[chaimsimcha]

It's easy to roll back to 17.0.x.  Just uninstall 17.5, reboot, install 17.0.x (if you check the box to use the enhanced keyboard your host system will need a reboot).

Once you've installed 17.0.x, you should be back to normal.

If you get a notification that 17.5 is available on startup, just click the box to "skip this version"

Maybe they'll get it fixed in a future release.

I would really like to know why vnat.exe is blowing up processor cores to begin with.  If anybody knows the answer to that, it would be good information.
Thanks

[Yedeluge8]

Thanks for your solution.

I updated to v17.5, my computer fans became always working with very big sound, then I notice VMware NAT Service consume 20% CPU continuely.

I can not imagine why VMware made such a big bug or mistake.

[MondoBass]

When I updated to 17.5.0 I allowed VMware to upgrade my disk encryption. If I roll back will the older version be able to access the disk?

[Technogeezer]

---

@MondoBass wrote:

When I updated to 17.5.0 I allowed VMware to upgrade my disk encryption. If I roll back will the older version be able to access the disk?

---

No.

You'll have to unencrypt it on 17.5, then downgrade the virtual hardware version to version 20. Then you can start the VM on Workstation 17 and re-encrypt it with either full or partial encryption.

Or if you had the VM partially encrypted, you can create a new 17.0 VM and use the vmdk files of the 17.5 VM (the vmdk files aren't encrypted when using partial encryption)

[MondoBass]

Thank you for the quick response. I cannot remove encryption until I remove all snapshots, and that is something I would like to postpone. Also, I remember that I cannot remove encryption if the TPM device is installed. For now, I replaced the vmnat.exe file as suggested by jen2, which seems to resolve the problem.

I am a professional software developer, and it makes me uneasy to tamper with VMware Workstation. I am especially nervous about the "re-encryption" aspect of the update. I should never have permitted this.

Thanks again.

[MondoBass]

I forgot to ask...

Does re-encryption affect all previous snapshots? Or, is it only the snapshots since the re-encryption operation?

[jsmchiang]

upgraded to workstation pro 17.5 on win 11.  Had high cpu 20% vmnat.exe usage.

Replaced the vmnat.exe file and sovled the problem.

Thanks

[seth78]

Replacing vmnat.exe works like a charm. Thank you very much!

Windows 11 Pro 23H2 + VMWare Workstation 17.5.0

[brennansebastia]

Same here - 17.5.0 build-22583795

The in-product upgrade also broke my guest NAT network.

[TedFine]

I've been unable to find version 17.0 for download on the VMWare site.  It only offers me 17.5.

Any suggestions?

[seth78]

I have downloaded this file from first reply, Jen2. It works with my 17.5 version. 

[yurkam]

You can extract the vmnat.exe binary from the installer, it is "_vmnat.exe" in Workstation.cab.

[OKLakeGoer]

Reverting to the old version by opening the original install package/workstation.cab with 7-zip, extracting _vmnat.exe, renaming it vmnat.exe, and copying/replacing the one in c:\windows\syswow64 worked for me.  Appreciate the help everyone.

Of course, you need to stop the vmware nat service first.

[VMwareNATSucks]

Fix here!

https://communities.vmware.com/t5/VMware-Workstation-Pro/High-CPU-usage-by-vmnat-exe-after-upgrade-t...
"The only solution is to replace vmnat.exe in the C:\Windows\SysWOW64 with the old version 17.0.2. But you have to stop the service first (VMware NAT Service)"

EDIT: oops, didnt realize this was the same thread

[erobrich]

I tried:

- Uninstall VMware Workstation, clean folders, reinstall

- Replace vmnat.exe with the 17.0.2 version

I'm still without network in my 17.5 VMs set as NAT.

Guess I'm stuck using bridged networking for a good while.

[jen2]

---

@erobrich wrote:

- Replace vmnat.exe with the 17.0.2 version

---

Did you replace the file in the folder C:\Windows\SysWOW64 ?