Tracking too many interrupts with my tablet PC
I have been very happy with my tablet once I scanned my fingerprint to "calm down" the fingerprint reader software. I happened to notice the fan on the tablet was still running more often than what I expected after making that change. I figured I had something still causing the CPU to be used too much (thereby generating the heat which was causing the fan to run) and started troubleshooting again.
My first stop was Process Explorer. It gave me a big clue: something was using about 7% of the CPU time making "DPCs." A quick check on MSDN told me DPCs were Deferred Procedure Calls (aka "interrupts") and, essentially, they could cause a CPU to be used excessively. This seemed to jibe with what I was thinking, so I fired up Windbg to attach to the System process to see what was slamming the CPU with DPCs. It failed, of course, since the System process is protected and I can't attach to it.
Looking around, I found this article about using xperf to track DPCs. Talk about timing - it had only been written a few days before I needed that information. I read through the article and since I already had Windows symbols installed, I was set to go. I don't have a lot to add to that article since I was able to follow it pretty much step by step. I was able to drill down pretty quickly to see 2 possible drivers eating the CPU.
The top line here shows ndis.sys consuming 7.3% of the CPU over the time span I chose (a few seconds). The article stated that I could expand the view to show the calls being made, but for some reason, symbols were not resolving for me, and I just got blank lines for each call. Still, this gave me a good starting point, and I would also keep an eye on the USBPORT.SYS driver.
NDIS is used by networking, so I went to the control panel \ system \ device manager to see what was installed as far as network drivers go. I hazily remember something about a default NDIS driver in Windows 95 from my tech support days which was used if not 32 bit drivers were available, and I hoped to be able to use the device manager to get a version number of what my tablet was using.
Now, if I had one complaint about the tablet, it is the sheer number of drivers installed. I'm not joking when I say there are over 100 drivers total, and there were 4 network drivers. 2 were for 802.11 a/b/g (wireless and LAN), one was for Bluetooth, and there was an Nvidia nForce driver. Since I had to guess which was the culprit, I went for the Nvidia first, for no particular reason. I disabled the driver and waited a few seconds. The CPU fell to 0%, and the number of DPCs dropped to near zero. After a few seconds, the fan went quiet. I think I found the culprit.
I tried googling up Nvidia Nforce problems to see if there were other people reporting similar performance hits. I neglected to think about my wireless network not working since I had disabled this driver, but lo and behold, it still worked. I rebooted, verified the driver was not loaded, and still had network connectivity. I looked around and found a few scattered reports of problems with NVidia network drivers, but nothing definitive.
I'm tempted to leave it alone at this point, and keep my eye on Nvidia to see if they update their drivers. But I haven't fixed the problem - I've only eliminated a symptom, and I haven’t had time to find what functionality I may have lost. For instance, I did not have time to verify Bluetooth still working, so it may be completely broken at this point. I also have a wireless printer connected to which I need to print. And I still do not know why the USB driver is using more than 1% of the CPU, or why the storport.sys calls are taking so much time relative to all other calls.
Questions, comments, concerns and criticisms always welcome,
John