UDP port leak in Wmiprvse.exe when a WMI Group Policy filter is used

Assume that you apply a Group Policy setting that uses a Windows Management Instrumentation (WMI) filter to a Windows Server 2016, Windows Server 2012 R2, Windows 8.1, or Windows 10-based computer. After some time, PolicySOM (WMI Policy Provider) consumes all available dynamic remote procedure call (RPC) ports on the User Datagram Protocol (UDP) protocol. When this problem occurs, the computer becomes unresponsive.

• This problem is more visible on Active Directory domain controllers that apply a Group Policy policy every five minutes.
• This problem is more visible on operating systems on which the RPC port range is limited by using the netsh dynamic port command or an equivalent. In this situation, leaks consume a smaller pool of RPC ports.
• This problem is more visible on computers that are not restarted in a long time.

Additional symptoms information

The WMIPRVSE.exe process that hosts the PolicySOM provider can be short-lived. When the Wmiprvse.exe process finishes, and the work that has to run the WMI filter eventually becomes idle, the provider unloads. As long as the ALL providers value is set to IDLE, the process is terminated. The default time-out value for providers is two minutes in Windows Server 2012 R2.

You can use the netstat command to identify this problem. This command shows UDP port exhaustion for the same instance (PID) of Wmiprvse.exe. In this situation, the UDP port usage expands to additional ports regularly.

To determine whether your computer is affected by this problem, run the netstat -anob > netstat.txt command, and then open the Netstat.txt file by using Notepad or a different text editor. You may see the following lines or something similar:

This example shows that UPD ports 49234, 49283, 49399, and so on, belong to the Wmiprvse.exe process that is running in PID 6628.

Take additional samples a few hours or days later. To determine the run rate of the UDP port consumption, compare the number of ports that are used to your current restart interval or a modified restart interval for the computer that you are investigating.

Every time that the process loads and unloads WLDAP32.dll, a socket handle is allocated and is not released. Therefore, the source ephemeral port remains bound. This causes source port exhaustion over a long time.

This behavior is by design. It affects the way that WLDAP32.dll uses sockets in order to address a kernel limitation and prevent a deadlock that could otherwise occur on the system.

If you encounter the issue in Windows 10, to fix the issue, install the Windows 10 cumulative update that was released on May 17, 2018 or later cumulative updates. For more information, see May 17, 2018—KB4103720 (OS Build 14393.2273).

If you are using Windows Server 2012 R2 or Windows 8.1, use the steps in "Workaround" section to work around this issue.

To work around this problem, put the PolicMan provider in its own dedicated Wmiprvse.exe process. When the provider is unloaded, the Wmiprvse.exe process is stopped, and all sockets are closed automatically. To do this, run the following Windows PowerShell script:

$a = [WMI]'root\policy:__Win32Provider.name="PolicSOM"'
$a.HostingModel = "NetworkServiceHost:PolicSOM"
$a.put()

Note To reverse the change and put the configuration back to the original, run the following command:

$a = [WMI]'root\policy:__Win32Provider.name="PolicSOM"'
$a.HostingModel = "NetworkServiceHost"
$a.put() 

Although the Wmiprvse.exe process that hosts the PolicySOM provider is usually short-lived, this problem can still occur in some cases. This is because the WMI query pressure from a service that is running under the same Network Service security context may cause long process run-times that expose the memory leak. This usually occurs when you run health agents that are configured to use very aggressive checks. For example, System Center Configuration Manager makes aggressive checks.