2

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.

Improve this question
0

1 Answer 1

Reset to default
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.

Improve this answer
3
  • 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .