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.
