I have a Windows 2003 server that occasionally hangs. When it hangs, I can still use it through the console, but externally, it is completely unresponsive. It won't even respond to pings. However, restarting it returns it to a normal state for anywhere from a few hours to 2 weeks.

When it is hung, I do not see any particular process in the task manager that has high CPU usage, though the CPU meter shows that the CPU hovers between 30%-50% usage. The Process Explorer indicates that 30%-50% of the CPU is being consumed by the "interupts" process. I know this is not a real process, but I can't figure out what's causing it to be so high.

The consensus seems to be that the IDE controllers tend to switch from DMA mode to PIO mode, but I am not seeing this in the Device Manager before or after the hang.

How can I determine what devices/drivers contribute to this?

Some additional details: This is a Dell 860 PowerEdge running Windows 2003 R2. It has a dedicated RAID controller. Not sure if this is relavent, but when I open the device manager, there are 4 USB controllers that say the driver is either missing or corrupt, though this machine has no usb device connected.


1 Answer 1


If your system does not response to pings and shows a high level of interrupts, I would suspect the NIC first.

You can use the Kernrate Viewer which gives some information on what device drivers are using the CPU, but I would just replace the NIC (at least the PE 860 has a full-height PCIe slot to allow for quick replacements) and see if it does mitigate the problem.

  • Thanks @syneticon-dj. Am I mistaken or does Kernrate require Excel on the server? If it does not, can you tell me what command-line arguments to pass to the exe's?
    – mhildreth
    Sep 12, 2012 at 12:50
  • Also, this machine has two NIC cards already (not sure if both are onboard). I had the same thought and disabled the one that was originally in use and switched over to the other. Doing so seems to have had no effect.
    – mhildreth
    Sep 12, 2012 at 12:51
  • OK, so simply running the kernrate exe for 10 seconds or so captured enough data to show that the problem was a Broadcom NIC driver. I didn't need any command-line switches. I didn't realize at first that the kernrate output would only be in the command-line window (by default) - I was just double-clicking the exe and not seeing anything. Launching it from the command line was all I needed.
    – mhildreth
    Sep 13, 2012 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.