Last Friday I was trying out GMER, a rootkit detector and remover on our oldest XP machine using IDE ATA/ATAPI disks. It seemed to work fine, but since there were lots of files, I stopped it after a couple hours. Then I noticed something: the cursor was 'jumpy' and the computer seemed a bit slow. GMER (http://www.gmer.net/) didn't find anything bad, but that was the only thing that I had used on the machine that was out of the ordinary. So I shut the computer down until Saturday evening. I started it up to do backups. The Acronis backup software claimed it was going to take 6 hours to do an incremental backup - it usually takes less than half an hour. What was going on?
I noticed that the cursor was still jumpy. Strange. I started Task Manager and saw that most CPU activity was in 'System Idle Process' so there wasn't any specific program hogging CPU time. So I ran a chkdsk from the command line. It was so slow I had to terminate it. More strangeness. I checked the event log and saw no errors - I was looking specifically for disk errors. Just to be safe I did a chkdsk /f and rebooted. Went away for an hour and XP was finally back up when I came back. But still the cursor was jumpy.
Next I used SysInternals (MS) Process Explorer and saw the real problem: Hardware Interrupts. Normally interrupts account for less than 5% of CPU time, but they were going up into the 90%+ range whenever any program touched the hard drive. This meant something was wrong with the hard drive itself or the interface. After a long search on Google I found the answer.
Apparently XP will change the disk controller transfer mode from the DMA transfer modes (Ultra DMA in our case) stepwise all the way down to slow PIO (parallel IO) mode in steps if six or more timeout or CRC errors are seen. By going to Computer Management/Device Manager I could see that the boot drive C: was in PIO mode. Apparently GMER hit the disk hard enough (combined with the age of the machine) that it had enough drive errors to lower it to PIO mode.
How get it back to Ultra DMA mode: from Device Manager right click on the offending IDE channel (drive 0) in my case, then select Uninstall. Now restart. Sounds scary, but it's not because it does actually reboot OK. After it starts, it will ask you to confirm changes and it will restart again. Problem solved.
This process and a full explanation of what is happening can be found at:
http://support.microsoft.com/kb/817472 - don't bother with the hotfixes, they apply to earlier SP's, I had SP3. The section marked 'workaround' is the one I used.
I don't think I'll be using GMER on that particular machine again, but I've used it on other machines - no rootkits.
3 comments:
Had this problem too, after using GMER. Atapi errors in System log. Interrupts eating 50% of CPU time, according to ProcessHacker (a very nice Task manager alternative). Wonder what GMER does to those IDE channels...
Uninstalling the IDE channel in question helped! Thanks!!
I have the same experience with GMER 2.1.19163.0, Windows XP SP3 and older nForce4 Ultra based motherboard.
While running GMER there are several errors in Event Log 'The driver detected a controller error on \Device\Ide\IdePort2'. After a while I noticed the CPU goes to 100% when copying a large file that means the only thing. Yes, the transfer mode of SATA drive had changed from UDMA6 to PIO. I have deleted the device and rebooted which seems to fixed it.
You are not alone with the issue.
And another confirmation on my old ThinkPad R51 that has Intel based chipset and IDE controller. Windows XP SP3 and the same result, changed to PIO.
I run chkdsk /f and it did not find any issues. Anyway I don't trust the GMER software anymore.
Post a Comment