Archive for December, 2013

Windows 7 System Image Restore – Three Days of Frustration

December 18, 2013 10:00 pm

If you ever need to recover a Windows 7 system image onto a new hard drive, I hope you don’t have to go through the same pain I just did. It took me three days to get my main PC back in working condition…

A few days ago Windows finally alerted me to an impending disk failure (after having silently logged the problem to the event log for over three months – gee, thanks Windows!) It was trying to be helpful by encouraging me to make a system image backup before replacing the drive, which I did. That took a while, of course, with 336 GB to transfer. I used an external USB-to-SATA bridge for this. But it took nowhere near as long as the recovery odyssey I ended up with.

My surprises started when attempting to restore this image on a fresh drive. My system has three hard drives, one for the OS and two for data. I attempted to restore the image using a regular Windows 7 install DVD. I had several lying around, but none of them would work. I ended up burning a new one with Windows 7 Ultimate x64 SP1 and using that.

The first attempt at restoring took over 20 hours. I had connected both the new drive and the old drive (plus my two data drives) to the system via its plentiful SATA connectors, so it was a SATA-to-SATA transfer, which I expected to go really fast. Nope. And, apparently, having all disks connected and active while restoring is bad, since (as I think I’ve now concluded) that messes up the drive letter assignment of the restored image. Somehow the restored image ends up with a non-C:\ drive letter.

Not realizing that this was the problem, I tried using Acronis True Image Home 2012 to create a fresh backup image of the failing drive, and then restored that. Same problem. At least Acronis didn’t take over 20 hours to restore the data…

I ended up with two things that needed to be done: The boot configuration had to be fixed (as I later found out this was because somehow my original drive configuration had been messed up between creating the original Windows System Image Backup and the Acronis Image backup). On top of that, I had to somehow fix up the drive letter mapping so that C: would once again be C: – and not F: The drive letter mapping problem showed itself in that the OS would boot (once the boot config was fixed), but after logging in, it would be stuck at “Preparing Your Desktop”, and sometimes even get to a blank blue screen. From there I could start Task Manager via Ctrl+Alt+Del, and then a command prompt, which showed me that the OS thought it was living on the F: drive.

Here’s the boot configuration fix (applied by booting from a Recovery Disk or Windows install DVD):

bcdedit /export C:\BCD_Backup
c:
cd boot
attrib bcd -s -h -r
ren c:\boot\bcd bcd.old
bootrec /RebuildBcd

The drive letter mapping was harder. I couldn’t do it from the Recovery Disk (which I also created along the way), nor by the Task Manager trick (halfway “booted” into the user account). I finally found the trick: Boot from the old disk, load the SYSTEM registry hive from the new disk, and swap the value \DosDevices\F: in HKLM\SYSTEM\MountedDevices with \DosDevices\C:

So here’s the boot drive letter assignment fix based on the above trick for modifying the registry of a non-booting system:

  1. Note what drive letter the non-working disk has for itself based on the “boot halfway” command-prompt (F:, in this case);
  2. Boot the working disk;
  3. Determine what drive letter the working disk has (C:, in this case);
  4. Start regedit, highlight the [HKLM] branch, select the
    regedit option ‘File->Load Hive’, and load the file
    ‘F:\Windows\system32\config\system’ under a {dummy} name;
  5. Locate the two registry entries:

    [HKLM\{dummy}\MountedDevices  \DosDevices\F:]
    [HKLM\{dummy}\MountedDevices  \DosDevices\C:]

  6. Rename the value \DosDevices\C: to some other name, such as \DosDevices\Z:
  7. Rename the value \DosDevices\F: to \DosDevices\C:
  8. Rename the value \DosDevices\Z: to \DosDevices\F: 
  9. Highlight the {dummy} branch, select the regedit option ‘File->Unload Hive’, and exit regedit.

I don’t think I’ve ever had this much trouble restoring an image. I guess the real lesson is “don’t restore the image with any other drives active on the system, and if possible, use a USB bridge for the disk you’re restoring from”. Microsoft, this should be easier!!!