Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 03, 2016, 10:00:02 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: A possible timesaver if restoring a drive image fails (ShadowProtect, etc.)  (Read 2929 times)

tranglos

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,079
    • View Profile
    • Donate to Member
In the course of restoring my XP image using ShadowProtect, I have had what can graciously be called a "learning experience" :) So here's a quick tip that may save others time and sanity:

If you have restored an image of the system drive, but the OS won't load, boot into your recovery environment and check whether the restored boot.ini file has the same exact contents as the boot.ini file stored within the image. If the contents are different, manually copy all the exact lines from the original boot.ini to the restored one. Having done that, you may just be home safe.

Explanation:

I was restoring a bootable XP image using ShadowProtect, but the scenario may also apply to other imaging software (especially that some vendors appear to license their technology from StorageCraft). It seems to be a somewhat common occurrence that on trying to boot from the restored image you may be greeted with the following error message:

Windows could not start because the following file is missing or corrupt:
Windows_root\System32\Hal.dll
Please re-install a copy of the above file.


Depending on what's been written to boot.ini, the message may be more ominous:

Windows could not start because of a computer disk hardware configuration problem.

If this happens, don't panic. The OS loader is already running, so your disk and your partition are probably fine. What happened is that the recovery environment may not have restored your original image exactly as it was, but may have fiddled with the contents of the boot.ini file, which tells the loader where to find the operating system files. This is more likely to happen if you have a dual-boot system, or if you have multiple partitions on the drive being restored, but these scenarios are not required for the problem to occur. I have a single drive with a single partition on it, no dual-boot at all, yet I got the same error.

In this lengthy thread on the ShadowProtect forum you will find some explanation of what's going on. Basically, ShadowProtect is trying to figure out the correct sequence of disks in the system and partitions on those disks. The correct sequence numbers are necessary to generate a working boot.ini file. However, there is a number of things that may throw off ShadowProtect's analysis. In my case it was an external drive connected via Firewire, but it could be an eSATA drive as well. Apparently, such drives are indistinguishable from internal HDDs, so they are included in the count. How ShadowProtect tries to determine the ordering of the drives I have no idea, but from the thread referenced above it seems that it cannot always arrive at the correct sequence.

The problem is that ShadowProtect doesn't offer a hint that its determination is not exactly iron-clad, nor does it admit to have fiddled with the contents of boot.ini. This becomes an interesting psychological issue: I was using a highly acclaimed, high-tech product, and the product was telling me that boot.ini was OK and that the partition was healthy and bootable - so I trusted it. It never occurred to me that it may not have restored my boot.ini exactly as it was stored in the image, so I did not check, and thus wasted much time on hand-wringing, cursing and frantic googling for hal.dll-related errors.

The solution was to compare the original boot.ini with the one ShadowProtect was actually restoring. Turns out, they differed in the number assigned to the system partition. I changed (1) to (0) in two lines, to match the original boot.ini, and I was back in XP in no time.

I should add that once I made that change, ShadowProtect's diagnostics tool insisted my boot.ini was "broken" - since it did not match its internal determination of how the drives in my system are laid out. Never mind, though it would have been helpful to have a hint in the software that you cannot always trust ShadowProtect's opinion on when the file is correct, and when it is borked. As always, trust your own reason more than you trust the software...


On edit, though it's probably obvious: the above applies to a system whose drives have not changed in any way between the time the image was made and the time you are restoring it. If you have added or removed drives or partitions, then naturally the new boot.ini will have to be different than the original one. And likewise, your recovery CD may not create it correctly. The thread I linked to has some advice on what a correct boot.ini file should contain.
« Last Edit: January 19, 2010, 05:24:29 PM by tranglos »

tranglos

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,079
    • View Profile
    • Donate to Member
...Of course, restoring a Windows 7 image is harder still, because there are two partitions to restore. Remember, by the way, to always image the "reserved" system partition that Win 7 installer creates and that has no letter assigned in the system. Win 7 won't boot without this partition, and it's easy to forget it even exists.

That said, after I tried restoring the two Win 7 partitions, I still had to resort to the installation disk and use the "Repair computer" feature before it would boot. I don't have a good procedure for this yet.