Hard Drive Install Problems

For many of you this is going to seem like a really silly thing to write about. Of course you do this and that when you install a new hard drive. But, I've become complacent in my old age and just didn't think of it. Regardless ...

I installed a new 250 GIG Western Digital HD and killed my system.

My problem was self inflicted (sort of). I installed a new hard drive to handle video files (250 Gigs). Problem: I didn't make any allowance for the drive in the BIOS setup. So the new drive was installed as an unknown type of media and the transfer mode was set to PIO (Programmed Input/Output) instead of UDMA-5 (Ultra Direct Memory Access). This is a really, really slow mode of disk access. And, I was unaware this had happened. Didn't really discover it until I had the system back up and running and I started to test access to the new hard drive.

As soon as I had the new drive formatted with NTFS and recognized by Windows XP, I started to copy over data from my primary drive. In the process of copying over a single file that was about 16 gigabytes, the computer flopped up with a blue screen of death. When that happened the partition where the OS resides was unceremoniously dropped, not properly dismounted. From then on booting was impossible.

Partition Improperly Dismounted

I poked carefully at the computer with various tools attempting at all costs not to alter any data written to the disk. Using Linux (Knoppix stand alone bootable CD) I was able to view the partition and see that all my data was just fine. I tried Partition Magic and it reported the error message "partition improperly dismounted". While Partition Magic is able to cure many problems with partitions it was unable to fix this problem by itself. Searching for that term on the net I discovered the cure.

The fix was to run check disk (CHKDSK) to fix the way the file system was laid out. Specifically, "CHKDSK /p" was the command. However, a plain CHKDSK revealed a single bad sector so I actually ran "CHKDSK /r" which will fix the sector problem as well as the partition problem. Executing this command properly set the flags for the partition and file system so that it could be mounted and booted from once again.

But, the system was dead so how to run CHKDSK? That turned out to be very easy. Just boot from the Windows XP install disk. It allows for a console from which many common tools including CHKDSK are available to run from the CD.

I was back up and running in fairly easy order. My time invested in the actual fix was probably 5 minutes. However the computer took an hour or so to carry out that fix using CHKDSK. But once it was done I could boot with no problems.

PIO vs UDMA

Anyway, the system was up and running again. I started to look into the whys and wherefores of the crash. Since it happened using a brand new piece of hardware (new drive) I was pretty sure that the problem would be related to that.

The drive was abominably slow. I mean floppies would see fast compared to this thing. So, I started hunting out information on why a hard drive would slow down so drastically.

Up to this point in the trouble shooting process I didn't know or understand much about PIO. However, I soon discovered that there are many, well a couple of, modes of disk access. I also read on the net that occasionally transferring really large files with PIO access sometimes causes the OS to crash because it is trying to get something else done and the PIO method chews up huge amounts of processor power which prevent the OS from completing other critical tasks.

So, I discovered how to find the PIO/UDMA settings area and how to change these settings so the drive would become much better behaved in the system environment and also about 10 to 20 times faster. When I went there I discovered that, yeah, my new drive was set to use PIO mode

It was easy, so said all the initial sites. Go here, do this, do that and voila, you got a fast drive. But whenever I tried this the drive would ABSOLUTELY refuse to enter UDMA mode. So, I started looking into that. Turns out if a drive spits out 6 cumulative CRC errors Windows drops the transfer mode down a step at a time from UDMA-5 to UDMA-4 etc. until all that is left is the clunky DOS remnant PIO mode.

Microsoft Knowledge base article on this

And to make matters really bad, Windows LOCKS the access mode. You can't recover from this by simply resetting the access mode. But, I thought I was on the right track. Because when I tried to switch from PIO to UDMA it wouldn't take, I thought ...

AH HAH!! This is probably my problem. So, I sought out solutions to this situation. It involves registry hacks and was fairly easy.

Here's one of many sites that address this problem.

I embarked on trying to reset the access mode flag so I could return to full speed UDMA-5. But after each hack, when my "advisors" told me to just go back and re-enable the faster access mode, I would find that I was still locked into PIO. Egad, I was stuck. And believe me, video just won't work over a PIO connected hard drive. I was thinking I'd probably have to return the disk to the store and buy a new one that works on SATA instead of (P)ATA. I have that capability on the motherboard.

As a last resort, I decided to go into BIOS and see if the DMA capabilities were dedicated to individual channels of the ATA bus. What I found there was that NO, DMA (UDMA) was dedicated to each bus but not individual channels on that bus.

I was staring at the screen and saw "disk drives". Hmmm, I'll click on that and see how the BIOS recognized my drives. And that was where the problem lay.

The master on my primary ATA channel was described as a hard drive but the slave was listed as unknown. I had thought from previous experience with CD/DVD installs that the BIOS was sort of plug and play and would recognize the drive. But, nope. So, I switched this parameter to autodetect, rebooted and re-entered the BIOS and the drive was now properly recognized as a drive. I continued booting into the OS, looked at the location that indicates PIO vs UDMA and saw that the drive was now UDMA-5 setup. So, all that CRC error stuff apparently had nothing to do with me and all the registry hacking while not harmful was totally unproductive. My problem was that at the hardware level my computer didn't really know what was on the primary bus slave position of the ATA bus. Fixing that fixed everything else.

Compusa, I'm ready to come to work now! :-)