Windows 10 build 2004 issues with dnsapi.dll

jaltmann 16 Reputation points
2020-08-11T16:16:12.607+00:00

Hello,

We have an issue (possibly specific to a GPO in our environment) that causes issues with the dnsapi.dll library in build 2004. The behavior that happens after a domain join computer is freshly imaged with 2004 or is updated from a previous version is that if there is any network connectivity, lsass.exe will spike all cores to 100% CPU usage while trying to call dnsapi.dll and it will use multiple threads to attempt to execute. I was able to determine this using Process Explorer for sysinternals. This is platform independent and happens on both our Dell's and Lenovo's. If any network device is connected, this will result in a forever spinning login screen. If the network devices are disabled and the user profile is logged into, then a network device (wifi/ethernet) is connected, services with privilege escalations will fail due to the high CPU usage. If network devices are then disconnected, then after a few minutes cores free up CPU.

As a partial fix, I have replaced both 32 and 64 bit dnsapi.dll's with a version from Windows 10 build 1903 and the issue with lsass goes away and I'm able to log in and have no issues with high CPU usage or privilege escalations. The side affect of an older dnsapi.dll is that I'm unable to browse network shares and receive the following error in event viewer: "The DNS Client service terminated with the following error: The specified procedure could not be found".

The unfortunate thing is I'm unable to get a Microsoft resource because our org is under 500 people and our licensing partner can not even get a resource assigned to investigate the issue. If we are having this issue in our environment, I'm sure others are running into this as well.

CU KB 4565503 from the July 13 update does not fix the issue.

Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing
Windows for business | Windows Client for IT Pros | User experience | Other
{count} votes

11 answers

Sort by: Most helpful
  1. Anonymous
    2020-08-12T06:45:48.28+00:00

    Hi ,

    Based on my understanding, you have used process monitor and found lsass.exe will spike all cores to 100% CPU usage while trying to call dnsapi.dll in windows 10 2004. Is that right? Please feel free to let me know if my understanding is wrong.

    I have not received such feedback yet. It seems that there might be some early adopter issues at this time with Windows 10 2004, if possible, I would recommend you wait a bit until Windows 10 2004 matures with future cumulative updates.

    In addition, the Feedback Hub app lets you tell Microsoft about any problems you run in to while using Windows 10. You can report this issue to Microsoft directly with the Feedback Hub app.

    For more information on using the app, click here:

    https://support.microsoft.com/en-us/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app

    If this issue is urgent, I would also suggest you contact Microsoft Customer Support and Services where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

    You may find phone number for your region accordingly from the link below: 

    https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers

    ---Please Accept as answer if the reply is helpful---

    Best Regards,

    Candy

    0 comments No comments

  2. jaltmann 16 Reputation points
    2020-08-12T14:51:25.52+00:00

    You are correct, it appears to also be happening with the DNS Client (dnscache) service as well. It seems to be attempting to make calls to register the device in DNS through the DHCP process within the dnsapi.dll, it spins up multiple threads and maxes out all cores. Disabling the DNS Client service does not resolve the issue. If there is a service or process calling dnsapi. With the 2004 build of dnsapi.dll as a result of the processes getting "stuck" on calling the functions in the DLL, services like VPN (in our case Palo Alto's GlobalProtect) will fail to establish a tunnel.


  3. Douglas Williams 1 Reputation point
    2020-08-19T19:37:12.177+00:00

    I still have the identical issue with a batch of Lenovo laptops. They were all installed and domain joined with Windows 10 1908. As soon as they took the 2004 feature update, we have the issue you describe above: 100% CPU from dnscache service waiting for lsass.

    We still have no solution and have had varying success with assigning static DNS to the wireless adapter (8.8.8.8) or disabling network altogether (dnscache does not load without networking).

    Were you offered a valid solution for this? We are keeping 2004 on hold until we can get this resolved.

    0 comments No comments

  4. Douglas Williams 1 Reputation point
    2020-08-19T22:00:44.787+00:00

    Replacing dnsapi.dll with the 1909 version has remediated the issue on my Lenovo laptop. This is not a fix, but it's a start.

    Time to get moving on this, Microsoft!


  5. Anonymous
    2020-08-28T02:02:28.287+00:00

    Hi jaltmann,

    It seems this issue is related with NRPT rule, please remove NRPT rule and then everything will work fine.

    >>we do not have the same issue for virtual machines

    We can also reproduce this issue in windows 2004 VM, just make VM has internet access. As the steps below:

    1. Set up a window 10 2004 virtual machine with internal virtual switch and configured NRPT rule via GPO.
    2. Let the win10 2004 join the domain and apply the GPO (NRPT rule).
    3. After applying the GPO, I disabled the internal switch and enable the external switch to let the machine has network connectivity but without reachability to DC.
    4. Then we can see 100% CPU caused by DNS client service in task manager.

    ---Please Accept as answer if the reply is helpful---

    Best Regards,

    Candy


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.