Surmounting the Unmountable_Boot_Device Error

I had a job recently in which the customer's Windows XP PC would power-on self test (POST) but would display a blue screen with an Unmountable_Boot_Device error. I loaded a third-party partition management utility from a floppy disk and saw that the partition was intact and contained 9GB of data. This utility's error-checking tool showed numerous cyclical redundancy check (CRC) errors and other assorted errors. I choose not to let the utility fix any errors because I wanted to make an image of the partition before attempting any corrective measures.

The imaging software recognized the partition but would not run against it, reporting that the Chkdsk bit was set on the partition and that this problem had to be corrected before an image was possible. I tried making a sector-by-sector image, but the image got hung up on the Master File Tables (MFTs). The catch-22 here is that if the drive won't mount, XP's Check Disk (chkdsk.exe) tool won't automatically run.

I decided to use the Recovery Console (RC) on the XP installation CD-ROM to run the Chkdsk /r command manually. However, I wasn't prompted for the installation to repair. When I tried running the Chkdsk C: command instead, it got hung up when it reached about 10 percent completion.

So, I removed the drive, brought it back to my office, and installed it on a secondary IDE cable attached to my XP workstation. My idea was that, although it might not boot, with luck I'd get the customer's crucial data off it. To my astonishment, when I booted up my XP workstation, it saw the newly attached drive and spent about five minutes making corrections to invalid file entries and cross-linked files. This isn't exactly what I anticipated, so I was a little nervous about the outcome. However, when I went into Windows Explorer, there was the customer's drive. I was able to copy all his data to a CD-ROM.

I called the customer to let him know I saved his data. I also told him that with all the corrections that were made on his drive by my XP’s ChkDisk, I thought it might be possible to boot his machine. So, I returned to his office and reinstalled the drive. Unfortunately, it didn’t boot. Because the file structure was supposedly fixed, I decided to fire up the RC again and run the Fixmbr command. This time around I was prompted for the installation to repair. I selected his XP installation, after which I was prompted for the Administrator password. The customer had no idea what it might be.

I pulled out a third-party utility to reset the Administrator password. It let me reset it, and the PC rebooted. I went into the RC, but the new password didn’t work. Apparently, when resetting the Administrator password, you must be able to boot into the OS for the password change to take effect. But booting into the OS was the initial problem I was trying to solve.

A clean-slate XP reinstall had to be performed. However, had the customer known the Administrator password, things might have turned out differently.

—Bret Bennett

End of Article