Imagine my dismay when my new, fast-everything-dual-core-with-tons-of-RAM PC suddenly started running at around 50% CPU utilisation more-or-less constantly, even when it wasn’t supposed to be doing anything. You just don’t have these problems with Linux . Anyway so began the detective-work.
Most of the CPU utilisation appears to be Kernel-space:-
The obvious place to start is to find out which process(es) are doing the damage:-
Pretty consistently the culprit seems to be svchost with a process ID of 1468…it is running steadily at around 50%.
So what is it doing ? Microsoft’s Knowledgebase article 314056 says:-
The Svchost.exe file is located in the %SystemRoot%\System32 folder. At startup, Svchost.exe checks the services part of the registry to construct a list of services that it must load. Multiple instances of Svchost.exe can run at the same time. Each Svchost.exe session can contain a grouping of services. Therefore, separate services can run, depending on how and where Svchost.exe is started. This grouping of services permits better control and easier debugging.
Easier debugging my ass. Anyway, it goes on to give some information about how to find out what this particular instance of svchost is doing. The command:-
tasklist /svc /fi "pid eq 1468"
shows exactly which services are running under this particular process ID:-
So it only remains to figure out which of these services has gone awry. A little bit of guesswork comes in here, matching the abbreviated names from the output above to services. This isn’t too difficult. All I had to do was stop the services listed one-by-one until the CPU utilisation dropped to zero. At it turned out, the culprit was the “TapiSrv”, the Telephony service. This wouldn’t stop when I asked politely (which was a bad sign all by itself) and when it was the only one remaining the CPU utilisation was still at 50%. When I forcibly killed the svchost process from Task Manager the CPU utilisation finally dropped to 0%.
Hindsight is wonderful. It turned out that the reason the Telephony service wouldn’t stop was because it depended on the Fax service and it was the Fax service that was really stuck. Once I had figured that out it dawned on me that the problem began around the time I was (unsuccessfully) trying to send a Fax to my bank to berate them for their stupidity (but that’s a whole other blog entry). I have worked around the problem for the moment by disabling the Fax service and all is well again (by Windows standards, at any rate). I haven’t yet got around to working out what is wrong with the Fax service (the urgency has passed…I found another way to beat up the bank !)