Windows 2000 Inaccessible Boot Device, Recovery Console, and Chkdsk
Read about Alan Sugano's troubleshooting efforts for a client company whose server failed.
February 9, 2004
My consulting company received a call from a client company that said its server had received the dreaded “Inaccessible boot device” blue screen. The server was a Compaq ML350 with a 1GHz processor, 2GB of memory, and duplexed 36GB hard disks. The server was running Windows 2000 with Service Pack 4 (SP4) and Microsoft Exchange 2000 Server with SP3. Network administrators noticed that the server was running slow and decided to reboot it. When they restarted the server, they saw the "Inaccessible boot device" error message. When we arrived on site, we attempted to restart the server. The server would display the Win2K splash screen, but after 2 minutes, the machine would display a blue screen and the error message. At startup, the primary mirror displayed a message that hard disk failure was imminent. At this point, the problem looked like a bad primary mirror hard disk. This machine was mirrored using the Win2K Disk Manager. We removed the primary hard disk and created an emergency boot disk by using the instructions found in the Microsoft article "How to Use a Windows Boot Disk to Prevent Boot Failure in Windows 2000 or Windows NT" ( http://support.microsoft.com/?kbid=101668 ). We tried to boot to the secondary mirror but received the same error message. The company's last good backup was 4 days earlier, so we really wanted to save the data on the server. Using the Win2K CD-ROM, we attempted to run the Win2K Recovery Console (RC), but the server froze. As you know, the RC allows access to an NTFS partition to copy files and repair boot sectors. (For a complete set of RC commands, refer to the Microsoft article "Description of the Windows 2000 Recovery Console" at http://support.microsoft.com/?kbid=229716 ). We also used the Win2K CD-ROM to try to repair the Win2K installation, but the OS couldn't find an installation to repair. We then tried using the RC and repairing the Win2K installation on the primary mirror drive, but we had the same results. At this point, the chance of recovering the company's data looked slim. We purchased a new SCSI disk and installed a fresh copy of Win2K. You can install a hard disk that has an existing NTFS partition on it and have Win2K recognize it. We connected the secondary mirror to determine whether the disk was accessible. When connecting a hard disk from another computer that has one or more NTFS partitions, the partitions show up as the next available drives. In this case, the secondary mirror disk was showing up as F (formerly C) and G (formerly D). When we attempted to access F, we received an error message that the disk was inaccessible, but we could still access and read the information on the G drive. Fortunately, the company stored most of its modified data on the G drive. We used the command
chkdsk F: /f
to recover the F disk. The /f switch attempts to fix any errors on the hard disk. Chkdsk found and fixed quite a few errors on the hard disk, and afterward we could access the hard disk. The F drive was now available, so we decided to pull out the new hard disk and see whether we could boot off the secondary mirror by using the emergency boot disk. When we booted to the secondary mirror, the server came up. We looked at Event Viewer and noticed numerous messages that the hard disk had bad sectors. Evidently, when the primary mirror started to fail, rather than failing all at once, it died slowly enough that the secondary mirror mirrored all the garbage on the primary mirror, which caused both hard disks to become inaccessible. I’ve also seen this happen with hardware RAID controllers; the rebuild utility usually can't recover the data on the hard disks, and the array must be reinitialized from scratch. In this case, the client didn’t lose any data and had only a day of downtime. If you run into a similar problem, don’t forget Chkdsk. It could be your best friend.
Tip
Are you running or planning to upgrade to Exchange Server 2003? If you use Symantec Mail Security 4.0 for Microsoft Exchange (SMS for Exchange—the only version that supports Exchange 2003) with your Exchange 2003 server and your server is heavily used, you might want to postpone the upgrade. If the Exchange server experiences a heavy load with SMS for Exchange active, users can't access their messages. When a user double-clicks a message in Microsoft Outlook, the program freezes and users must close it by using Task Manager. Event Viewer contains no errors, and a server reboot temporarily fixes the problem. This happens with SMS for Exchange 4.0.10.459 and 4.0.10.458. We are working with Symantec to resolve this problem.
About the Author
You May Also Like