BUG: VMware NAT Service high CPU usage build-22060606

[jen2]

After a while, VMware NAT Service (vmnat.exe) will use 100% of a single core. restarting the service will resolve the issue. But then again after while it will start using 100% of a core. The internet will still work even when high CPU usage.

[versat]

Here is my small PowerShell script to regularly restart the buggy VMware NAT Service, maybe someone finds it useful:

# Since the VMWare NAT service is buggy and completely uses a CPU core after a while, we restart it regularly so the high CPU usage is at least not permanent.

# Check if the script is running with administrator rights
$isAdmin = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

if (-not $isAdmin) {
    Write-Host "This script requires administrator rights. Restarting with elevation..."
    # Restart the script with elevation
    Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs
    # Exit the current non-elevated instance
    Exit
}

$RestartIntervalMinutes = 10

while ($true) {
    Write-Host "Restarting buggy VMWare NAT Service..."
    # Restart the VMWare NAT service
    Restart-Service -Name "VMWare NAT Service" -Force
    # Wait for the specified interval before restarting again
    Start-Sleep -Seconds ($RestartIntervalMinutes * 60)
}

[MPKLLC]

The cynic in me says maybe the next major version number. That way we must purchase the upgrade to get the fix.

[DataPollution]

I can corroborate that I am experiencing the same issue. Despite disabling the virtual machine itself and closing VMware Workstation entirely, the service continues to run, consuming between 10% and 16% of system resources. I am currently utilizing VMware Workstation Pro version 17.5.1, build number 23298084.

[DataPollution]

I can corroborate that I am experiencing the same issue. Despite disabling the virtual machine itself and closing VMware Workstation entirely, the service continues to run, consuming between 10% and 16% of system resources. I am currently utilizing VMware Workstation Pro version 17.5.1, build number 23298084.

[gjiewfjsdifdjif]

I encountered this issue on 17.5.1. Here's what I found:

0:004> ~
   0  Id: 16fc.5f80 Suspend: 1 Teb: 02a0c000 Unfrozen
   1  Id: 16fc.3e1c Suspend: 1 Teb: 02a18000 Unfrozen
   2  Id: 16fc.3f48 Suspend: 1 Teb: 02a1b000 Unfrozen
   3  Id: 16fc.3df4 Suspend: 1 Teb: 02a1e000 Unfrozen
.  4  Id: 16fc.69a8 Suspend: 1 Teb: 02a78000 Unfrozen
0:004> ? 3f48
Evaluate expression: 16200 = 00003f48
0:004> ~2s
eax=0000000c ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000017
eip=76f8586c esp=039ff860 ebp=039ff8d0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
win32u!NtUserMsgWaitForMultipleObjectsEx+0xc:
76f8586c c21400          ret     14h
0:002> k
 # ChildEBP RetAddr      
00 039ff85c 76b1c8aa     win32u!NtUserMsgWaitForMultipleObjectsEx+0xc
01 039ff8d0 76b1c7dc     USER32!RealMsgWaitForMultipleObjectsEx+0x7a
02 039ff8f0 76b1c77f     USER32!MsgWaitForMultipleObjectsEx+0x4c
03 039ff90c 00433348     USER32!MsgWaitForMultipleObjects+0x1f
WARNING: Stack unwind information not available. Following frames may be wrong.
04 039ffaf4 00445391     vmnat+0x3348
05 039ffb10 77797c5e     vmnat+0x15391
06 039ffb6c 77797c2e     ntdll!__RtlUserThreadStart+0x2f
07 039ffb7c 00000000     ntdll!_RtlUserThreadStart+0x1b

0:002> gu
eax=0000000c ebx=00000000 ecx=e1a60000 edx=00000000 esi=00000000 edi=00000017
eip=76b1c8aa esp=039ff878 ebp=039ff8d0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
USER32!RealMsgWaitForMultipleObjectsEx+0x7a:
76b1c8aa 8b4dfc          mov     ecx,dword ptr [ebp-4] ss:002b:039ff8cc=08761b23
0:002> gu
eax=0000000c ebx=00000000 ecx=0be9e3f3 edx=00000000 esi=00000017 edi=00000017
eip=76b1c7dc esp=039ff8ec ebp=039ff8f0 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
USER32!MsgWaitForMultipleObjectsEx+0x4c:
76b1c7dc 5e              pop     esi
0:002> gu
eax=0000000c ebx=00000000 ecx=0be9e3f3 edx=00000000 esi=00000017 edi=00000017
eip=76b1c77f esp=039ff90c ebp=039ff90c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
USER32!MsgWaitForMultipleObjects+0x1f:
76b1c77f 5d              pop     ebp
0:002> gu
eax=0000000c ebx=00000000 ecx=0be9e3f3 edx=00000000 esi=00000017 edi=00000017
eip=00433348 esp=039ff928 ebp=039ffaf4 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
vmnat+0x3348:
00433348 8bf0            mov     esi,eax

 EAX is always same value between different stop.

0:002> g 43eb85
eax=02e3daa0 ebx=00000001 ecx=00000000 edx=0000000c esi=02e42f10 edi=0000000c
eip=0043eb85 esp=039ff8e8 ebp=039ff918 iopl=0         nv up ei pl nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000213
vmnat+0xeb85:
0043eb85 395624          cmp     dword ptr [esi+24h],edx ds:002b:02e42f34=00000016

0:002> dd 491378 L1
00491378  02e3d578
0:002> dd 2e3d578 L17
02e3d578  000001dc 000001e4 00000228 00000254
02e3d588  00000298 000002c4 000002fc 00000318
02e3d598  00000314 00000338 0000034c 00000348
02e3d5a8  00000360 00000308 00000378 00000384
02e3d5b8  00000380 0000038c 00000398 00000344
02e3d5c8  00000340 0000032c 00000304
0:002> dd 491374 L1
00491374  02e3daa0
0:002> dd 2e3daa0 L17
02e3daa0  02e22b40 004975c0 02e22948 00497520
02e3dab0  02e42c18 02e41b18 02e43820 02e42b80
02e3dac0  02e42fa8 02e43430 02e43040 00000000
02e3dad0  02e42f10 00000000 00000000 00000000
02e3dae0  00000000 00000000 00000000 00000000
02e3daf0  00000000 00000000 02e44968

0:002> dd 2e22b40+24 L1
02e22b64  00000000
0:002> dd 4975c0+24 L1
004975e4  00000001
0:002> dd 2e22948+24 L1
02e2296c  ffffffff
0:002> dd 497520+24 L1
00497544  00000002
0:002> dd 2e42c18+24 L1
02e42c3c  00000015
0:002> dd 2e41b18+24 L1
02e41b3c  0000000c
0:002> dd 2e43820+24 L1
02e43844  0000000d
0:002> dd 2e42b80+24 L1
02e42ba4  00000012
0:002> dd 2e42fa8+24 L1
02e42fcc  00000013
0:002> dd 2e43430+24 L1
02e43454  00000003
0:002> dd 2e43040+24 L1
02e43064  00000014
0:002> dd 2e42f10+24 L1
02e42f34  00000016

I guess it's because ResetEvent() logic was skipped, hope these info can troubleshoot this issue. I attached a minidump for further investigation.