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 AHCI, so this turn of events
was unexpected. I tried again, this time loading the Intel
RST RAID driver
for AHCI 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 AHCI 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.

 

Hoops to jump through

Have you run into any unexpected difficulty when attempting
to install Windows? Or, have you found a peculiar BIOS bug on computers from a
particular vendor? Or, perhaps, do you want to criticize my friend for running
a Windows installation from a laptop in RAID0? Speak your brains in the
comments section below.