Whenever anyone finds themselves in a situation like this, the first step is to stop each of the hosted services one-by-one, waiting a few moments between each, and checking to see if the usage drops. Once you have narrowed down the problem to the specific service, then you can do a web-search to find out if others have experienced the same problem.
In this instance, it was likely indeed the DNS service (Mikle did not indicate why he thinks it is not, and his assumption about the HAL is specious).
Of the services indicated, the only one that is known to cause a 100% CPU load is the DNS service. (The only references to a high CPU load in regards to the other services is with Vista+ where they are sharing the same svchost instance as the DNS service. Sadly it often ends up going undiagnosed.[1][2]) That it would only have taken 25% of the CPU load makes sense because he said it was a four-core processor, so the DNS service was using 100% of the core it was using.
The problem occurs whenever the HOSTS file grows “too large”; for some reason, whenever the HOSTS file has too many entires, the DNS service goes into a tail-spin, starts pegging the CPU, and never recovers (no, leaving it a long time to eventually finish does not work because it never finishes, even after days).
What had likely happened in this case is that Mikle had downloaded and installed a large HOSTS file like those available from some MSMVPs or had used SpyBot’s immunization function.
Unfortunately the only option in this case is to either strip the HOSTS file down to only a few entries, or to disable the DNS service.
Note that once the DNS service flies off the handle, you will not likely be able to simply stop it like a normal service; you must actually kill the instance of svchost.exe that is hosting it. This isn’t so bad in XP because it usually gets its own copy, but in 7, it shares a copy with a few other services (though nothing critical, so you can simply re-start the other services once you have disabled the DNS service).
Best Answer
This issue occurs because a handle leak occurs in the Winmgmt service after you install Windows Management Framework 3.0 on the computer.
Note The Winmgmt service is the Windows Management Instrumentation (WMI) service within the Svchost.exe process that is running under the LocalSystem account.
To fix this, check this link : https://support.microsoft.com/en-us/kb/2889748