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

[jen2]

It is a very aggressive bug I have already reported here https://communities.vmware.com/t5/Workstation-2023-Tech-Preview/BUG-VMware-NAT-Service-high-CPU-usage-build-22060606/m-p/2978665#M5

 

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)

 

I will upload the file for anyone having this bug.

Attachment(s)

vmnat.zip   193 KB 1 version

[visentet]

Many thanks, I was already thinking about a downgrade of entiero VMware.

 

[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.

[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

[OUrvar]

Thanks a lot, it fixed my problem!

[kelubi1980]

I also encountered the same problem, the solution you provided works, thank you very much.

[subcontracting]

I'm using 17.5.0 build-22583795, but still have the problem. Is there any news about official hotfix for this bug? I know that vmware posting their relises quite rare, but this bug is too obvious.

[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.

[Christian Scherwinsky]

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:

[VMware Community Member]

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?

[VMware Community Member]

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.

[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.

[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.

[louyo]

This was reported during the trial:

https://communities.vmware.com/t5/Workstation-2023-Tech-Preview/BUG-VMware-NAT-Service-high-CPU-usage-build-22060606/td-p/2978665

His "fix" seems a little drastic. Hopefully, someone else has a better one. 

If you have support contract, you might want to contact them.

[jen2]

That was me, and it was the same fix

[louyo]

Sorry about that, I was typing while you were entering. Should have double checked.

Lou

[Maxvatar]

Hi Peter,

same here. The only proper solution is to uninstall 17.5 and download "VMware-workstation-full-17.0.0-20800274.exe" from VM site ... it is still available there.

I wonder why VMWare release the 17.5 build when the high-cpu-usage bug of vmnat.exe is known from prerelease version, as Jen2 mentioned. It is rather weird in case of such software company as VMWare is.

Best regards

Tomas

[louyo]

Voice of experience: The devs said fix it, the suits said ship it. 

[jen2]

---

 wrote:

Hi Peter,

same here. The only proper solution is to uninstall 17.5 and download "VMware-workstation-full-17.0.0-20800274.exe" from VM site ... it is still available there.

I wonder why VMWare release the 17.5 build when the high-cpu-usage bug of vmnat.exe is known from prerelease version, as Jen2 mentioned. It is rather weird in case of such software company as VMWare is.

Best regards

Tomas

---

 wrote:

Same problem.  I wish I knew about this bug beforehand.  I'll try to revert now.

I would not recommend to revert unless you don't care of security! There are lots of CVE fixes.

The best way IMHO id you care about security is to replace only the vmnat.exe with old version I attached in post 2

 

[seekay3309]

Sigh.  I already re-ran the 17.0 Installer, but it wouldn't downgrade 17.5 to 17.0.  I un-installed 17.5 and re-installed 17.0.  All settings (license keys, drive sharing, VMs) had to be put back.  I also had to restore a Windows VM from a week-old backup so I lost a few minor updates/changes (but nothing major).  Fortunately, I monitor my CPU utilization and background processes or I wouldn't have known.

The Installer I had this issue with is VMware-workstation-full-17.0.2-21581411.exe.  Hopefully a new Installer with the fix gets posted soon so others don't have this issue too.

And yes.  I am security conscious.  That's why right off I didn't install a .exe file posted on a forum.

[jen2]

---

 wrote:

Sigh.  I already re-ran the 17.0 Installer, but it wouldn't downgrade 17.5 to 17.0.  I un-installed 17.5 and re-installed 17.0.  All settings (license keys, drive sharing, VMs) had to be put back.  I also had to restore a Windows VM from a week-old backup so I lost a few minor updates/changes (but nothing major).  Fortunately, I monitor my CPU utilization and background processes or I wouldn't have known.

The Installer I had this issue with is VMware-workstation-full-17.0.2-21581411.exe.  Hopefully a new Installer with the fix gets posted soon so others don't have this issue too.

And yes.  I am security conscious.  That's why right off I didn't install a .exe file posted on a forum.

---

It is the original file from VMWare 17.02 and it is signed by VMWare. The file is scanned by vmware before published, and you can check it using https://www.virustotal.com/gui/home/upload

Do you think I am so stupid to put a virus in the official VMWare forum? The file will be removed and I will be banned immediately

[Lippolt]

The vmnat.exe posted by Enthusiast is code-signed by VMware. At least a strong sign for being OK. 

[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.

[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. 

[merlingecko]

same problem here

[seekay3309]

Same problem.  I wish I knew about this bug beforehand.  I'll try to revert now.

[Chaim Simcha]

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

[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]

---

 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?

[Julio_Imdg]

Same problem.

Using vmnat.exe 17.0.2. did not help!

[jen2]

---

 wrote:

Same problem.

Using vmnat.exe 17.0.2. did not help!

---

Are you sure that you replaced the file in the C:\Windows\SysWOW64 folder?

[Lippolt]

Hi Jen2,

I am sure I have modified the file in the following directory: C:\Windows\SysWOW64. I found the directory via Task Manager and the process with the high processor load. As you know, you can see the path to the executable under Details.
Replacing the file can only be done after successfully stopping the service in the Service Manager. Since I did this, I have no more problems. As soon as I copy the original file back from VMware Workstations pro 17.5, the problem reappears.

Greetings from Hanover, Germany,
Peter

[visentet]

Hi Lippolt.

You don't have to copy the original, you have to leave the vmnat.exe from version 17.0.2. Start the service and work correctly.

[Julio_Imdg]

Hi Jen2!

Sorry, I did a Mistake.
Before replacement, I found two copies of that file vmnat.exe. One located in C:\Program Files (x86)\VMware\VMware Workstation and  the other in C:\Windows\SysWOW64 . I thought.. I replaced both. However I just have doublechecked. For some reason the syswow64 still had the 17.5 version. So, I replaced that file for the 17.0.2 version.
I have been monitoring cpu usage (two hours) using two WIndows 10 guest VM. No vmnat issues showed so far.

 

Thanks

[erobrich]

I hit this problem as well.  VMware NAT Service runs somewhere between 18 and 30% of my host's CPU all the time -- even when both guest and host are completely idle.  Additionally, guests lost DNS through NAT service, and I had to add manual DNS servers to all guests.  Host and guest are Win 11 22H2, fully patched.  I'd really rather not downgrade.  Hopefully 17.5.1 comes quickly and patches this?

[VMware Community Member]

You can download older versions from:

https://customerconnect.vmware.com/downloads/#all_products

 

[VMware Community Member]

thanks - works for me too. I am also waiting for the official fix - but thanks to the Community !!!

[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

 

 

 

[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.

[brennansebastia]

Same here - 17.5.0 build-22583795

 

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

[VMwareNATSucks]

Fix here!

https://communities.vmware.com/t5/VMware-Workstation-Pro/High-CPU-usage-by-vmnat-exe-after-upgrade-to-VMware-Workstation/m-p/2992080/highlight/true#M183202
"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]

---

 wrote:

 

- Replace vmnat.exe with the 17.0.2 version

 

---

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

[erobrich]

Yes I did. No it didn't fix it.

[jen2]

---

 wrote:

Yes I did. No it didn't fix it.

---

I think you have another issue, maybe related to this fix listed here

"

Wireless bridge connection might not work on a Windows host with DHCP configured

If you use Workstation 17.0.1 or above on a Windows host with DHCP mode configured, a wireless bridge connection might not work on the host operating system.

"

 

Try replace vmnetdhcp.exe (VMware DHCP Service) in the folder C:\Windows\SysWOW64\ and test. it could fix your issue

[erobrich]

Because I randomly lose DHCP or DNS or both so frequently on NAT'd VMs, I now have a script:

net stop "VMware NAT Service"
net stop "VMnetDHCP"
net start "VMware NAT Service"
net start "VMnetDHCP"

I run this as a scheduled task multiple times a day, and on-demand if my fans kick on or I lose DNS or DHCP.

I really hope I can get rid of it soon.

[erobrich]

Why is this possible?

- VMware NAT service is 24% CPU

- VMware Workstation VMX is 5.1% CPU

More of my machine is doing the NAT than doing the work!

As I was grabbing this screenshot, the NAT service jumped up to 30% while the VMX was at 0.9%. Wish I had grabbed that screen shot in time.

[Bl00dWolf]

Same problem.

Thx this helped

[johnnysrocket]

Same problem here too.  Surely they need to have a fix for this.

[VMware Community Member]

I have the same issue on updated Windows 10 host. Restart VMNAT service temporary solved this issue.

[inetbas]

Facing exact the same VMNatservice.exe eating CPU constantly even without starting VMware Workstation Pro 17.5
Secondly the NAT service fails after a while so the guest can't reach outside the host machine.

[LeoDavidson]

Are VMware ever going to fix this, or are they waiting for the one year anniversary or something?

[VMware Community Member]

Add me as one more user with vmnat.exe using lots of CPU.  Thanks to jen2 for uploading the 17.0.2 version of vmnat.exe - that fixed the issue.  Like everyone else, I am surprised VMware hasn't fixed this yet.  Maybe they are too busy dealing with the Broadcom acquisition?

[Maxvatar]

Hi all,

I've just install patch 17.5.1 and the symptoms are still the same! I just can't believe it, that no one in VMWare cares about this ... this is ridiculous.

I'm going to downgrade back to 17.0.2 again, hopefully it will work because new version of VMWare Tools comes with v.17.5.1.

Max

[VMware Community Member]

I love patching as much as the next guy. But in this instance I will stop patching Player (which is afflicted with the same issue) until VMWare wakes up and fixes this. 

By the sounds of it, things are not going well since broadcom took them over. My personal feeling is that Broadcom will destroy VMWare and milk only those large customers who can't afford to go elsewhere ... yet. 

For the rest of us, we should start making plans to look at alternatives like VirtualBox (Type 2 Hypervisor for home labs) and also Proxmox and others as a Type 1 hypervisor.

I love VMWare products and this neglect really makes me a saaaaaaad panda. 

[louyo]

I think I read where Broadcom sold desktop products. Not sure.

Hope this forum can stick with technical stuff. 

Oops. 

[gbohn]

I noticed that 17.5.1 is now available, but I didn't see the change log mentioning this issue as fixed. (Mostly a security fix from the sound of it and something related to the keyboard).

I have no idea if it was actually fixed anyway or not.

According to "The Register", Workstation is being sold off to a "Private Equity firm" KKR https://www.theregister.com/2024/02/26/kkr_vmware_euc_acquisitioj/ .

That doesn't exactly put me at ease...

[foobar4711]

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

[lhmxcter]

This is a serious BUG, which should be related to the DHCP automatic assign DNS address . This issue only occurs when Windows 7, Windows 10, and Windows 11 clients are enabled. XP and Linux systems do not have this problem. Manually specifying the DNS configuration in the client can solve this issue, but you need to restart the vmnat service after configuring it.

 Video

• vmnat-high-cpu.mp4

[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.

[VMware Community Member]

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

[VMware Community Member]

17.5.1 bug is still online

[VMware Community Member]

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. 

[VMware Community Member]

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.

[foobar4711]

Now VMware Workstation 17.5.2 Pro Release Notes it's supposed to be fixed. Updating ... and I don't see the issue anymore.

[Maxvatar]

Hello all,

I've ugraded VMW Workstation 17 to version 17.5.2. The symptoms of high CPU usage seem to be gone. It seems the problem is finally really fixed.

BR

MaX