Windows DNS Server using large amounts of nonpaged pool memory and file handles



A Windows server hangs, reboots, becomes unresponsive or network clients disconnect due to Dns.exe consuming a large amount of nonpaged pool memory and file handles.


Log on to the server using the local or domain Administrator account, open an elevated command prompt and perform the following steps.

1. Press the Windows Logo+R, type runas /user:administrator@domain.local cmd where domain.local is replaced by the name of the Active Directory domain or local server name and press Enter. The same task can be accomplished using the Command Prompt and Run as Administrator.

2. Type the Administrator account password when prompted and press Enter.

3. Type dnscmd.exe /config /socketpoolsize 1000 and press Enter.

4. Type net stop dns && net start dns and press Enter.

Additional Information:

This information pertains to Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.

Microsoft released security bulletin MS08-037 in July of 2008 for Windows Server 2003. The bulletin contains important information about vulnerabilities in the Windows Domain Name System (DNS) that could allow spoofing specifically those posed by the Kaminsky vulnerability. Windows DNS now uses source port randomization instead of a predictable and known port. The ports are configurable through registry settings and the pool size is configurable through a registry setting or using Dnscmd.exe.

Windows servers already experiencing heavy loads of non-paged pool memory may be impacted further by the installation of the Windows 2003 updates listed below or Windows servers running newer versions of Windows.

DNS Client (951748)
DNS Server (951746)

The installation of the updates in Windows 2003 causes Dns.exe file handles to climb above 5000 and increased non-paged pool memory consumption. This can cause servers to hang, reboot or become unresponsive and often client computers lose network connectivity to the server. A reboot will resolve the issue for periods or time, but the issue will generally resurface in two to seven days. The workaround is to reduce the number of sockets thereby reducing the number of file handles and nonpaged pool memory consumption. 32-bit operating systems are more prone to the negative affects of this issue. Refer to this KB article for further information.

Article ID: 1151, Created On: 11/7/2019, Modified: 11/7/2019

Feedback (0)