Recover from a dead RAID0 with Bootsect and DiskPart

Recovering from a dead hard drive in a RAID0 configuration may require a little old-fashioned command line knowledge.

Quite recently, I was asked by a friend to repair his laptop. The owner of this particular laptop is sufficiently competent to overcome basic issues one would encounter in Windows, so by merit of my being called in, clearly something catastrophic had happened. It is also important to note that the laptop itself, an Alienware M17xR3, while now two or three years old, has particularly impressive specifications, and one feature in particular that - on laptops - is reserved for high-end models: two 2.5" drive bays.

 

These drive bays are ultimately what caused the problem: normally, you're encouraged to use that feature to run two drives in RAID1 to prevent data loss. In this particular case, the two drives were configured as RAID0, which is a disaster waiting to happen. Attempting to turn on the laptop, I hear a faint repeating click over the hum of the dual fans on the bottom of the unit, and of the one larger fan on the USB-connected laptop cooler. After removing the drive to check it in a different (and less noisy) computer, my suspicions were confirmed - the drive suffered the "click of death".

Beyond the click of death

With the good remaining RAID member drive placed in slot 0 and a replacement drive (pulled from a different machine) in slot 1, I set to reinstalling Windows 7 on the laptop, when I ran into a peculiar problem: Windows setup didn't see the first drive at all, and refused to install to the second, informing me that setup was unable to create a system partition. In CMOS, I had changed the drive setting from RAID to ACPI, so this turn of events was unexpected. I tried again, this time loading the Intel RST RAID driver for ACPI support, which would be required for a RAID install, to no avail.

That is when I realized that the drive that was pulled from a different machine was formatted for an Ubuntu installation, and therefore didn't have the volume boot code for Windows 7. So, after exiting Windows Setup, I chose the "Repair your existing Windows installation" option, and from there opened the console. (This should be available in setup for Windows Vista, 7, and 8 by pressing Shift+F10.)

To initialize drives for Windows installation, a utility exists called BOOTSECT which configures the drives for you. For this particular problem, I entered:

bootsect /mbr /nt60 ALL

Note that with this command, all writable drives are being modified. This may present a conflict if you choose to boot from a USB drive to install Windows.

The second part of this fix involves the use of DISKPART, which has a wide variety of options that are useful to know about, though only a subset of these are being used for this particular fix.

Unlike most console applications in Windows, DISKPART must be loaded before any arguments can be given to it. This being the case, I entered:

diskpart

After DISKPART indicated that it has loaded, we should generate a list of available disks.

list disks

At this point, DISKPART correctly identified both disks installed in the computer, though the Windows Setup utility continued to ignore disk 0, the drive that had been in the RAID0 array. So, with the options of selecting disk 0 or 1, I entered the following commands.

select disk 0

clean

create partition primary 

Without passing parameters for "create partition primary" in DISKPART, it will automatically create a partition that spans the size of the disk from the first available part of the disk. In this case, as the disk was just cleaned, the offset would be zero. A drive letter is not assigned to the partition, but the partition is selected, so we must do that manually.

assign letter=c

format recommended quick

Quick format is cutting a corner, though the drive was just cleaned, so it probably is not necessary. Your mileage may vary.

I repeated these steps for disk 1, changing a "0" to "1" and assigning it the letter D, though the commands stayed otherwise the same.

Even more baffling

At this juncture, I attempted to start Windows Setup again, and without loading the Intel RST driver for ACPI support, Windows setup would properly identify the cleaned and formatted drives. (Loading the driver probably isn't necessary for just ACPI support, but in desperation, any plausible solution will be attempted.) However, it continually refused to install to any of the drives, indicating that it explained why in the error log. The error provided was "GetMachineInfo:Couldn't find boot disk on this BIOS-based computer". 

This was absolutely baffling - Windows Setup is running from the boot disk, so why can't it find where it was loaded from? Why would this prevent the installation of Windows?

As it turns out, this particular frustration I was experiencing is a semi-common BIOS bug found on Dell, and therefore Alienware, computers. The first drive in the boot sequence was the Windows 7 install DVD, not the target hard drive on which Windows would be installed. Swapping the values around and manually booting to the install DVD by selecting the option at boot finally allowed me to install Windows 7.