I'm a recent and enthusiastic convert to ShadowProtect. However, I now have a system down, and would appreciate some advice.

I've been doing C: backups on a 3 day (full) / 1 hr (incremental) schedule. I have done successful restores from one time point or another in all of my chains. This morning, however,  I tried to roll C: back to the last incremental point. The restore appeared to go normally, but on reboot I got a message to the effect that Windows can't boot because "...\System32\hal.dll is missing or corrupt".

I tried other restores from earlier incrementals in that chain, and from images in other chains. Same result. Ran image verification on all entire chains; all are said to be OK. Mounted one of the images in question and found that hal.dll is present, and is present on C: drive as well. 

Running SPD 3.5/XP-SP3 on a vanilla Intel-based system.

Any thoughts would be appreciated... 

To fix this issue:

Boot back up into the Recovery Environment, go to tools -> boot configuration utility. In the entry for your Windows volume  It should say "bootable" or "broken" It will most likely say broken. If it is indeed broken, then push auto repair. Then you should be able to boot.

Do you know what you did differently during this restore that caused this behavior?

 Bingo! That fixed it. Apparently boot.ini was corrupted.

Interesting... now I'm curious what could have caused that. I would swear that I did nothing different on that restore than I've done on other successful ones, except that I'm old enough to know better than to swear to anything.  :-)

Many thanks, SPT, for your reply.

 daveg,

Do you have other partitions on the HD? Strange that your previous restores worked and this one failed. Maybe your partition table order has changed.

Brian K:

Do you have other partitions on the HD? Strange that your previous restores worked and this one failed. Maybe your partition table order has changed.

You can get that hal.dll error when boot.ini on the active partition is pointing to a non bootable partition.

Yes, there are two partitions on that particular physical drive, C: & D:. However, there have been no (intentional) changes to the partition table.

Curious... I can see that it might be a good idea, after a system restore and while still in the recovery environment,  to do a quick check of Tools->Boot Configuration and be sure that the system partition is bootable, and if not make it so.

Thanks for your response...

daveg:

Curious... I can see that it might be a good idea, after a system restore and while still in the recovery environment,  to do a quick check of Tools->Boot Configuration and be sure that the system partition is bootable, and if not make it so.

It is very convenient to have that option for sure, and I always do that. The curious thing for me is why it didn't boot after the restore? ShadowProtect does just that, an "auto repair" if you will, upon finishing the restore process. Anyway, glad it's working. It's probably not worth thinking about any further. :)

 daveg,

I assume your partitions on the HD are OS first, then Data. Typically the partition table order would match this. The boot.ini would reference partition(1). If the partition table order was swapped to Data first, then OS, boot.ini would have to reference partition(2). You can test this in your computer. Change the partition table order and you will have to edit boot.ini.

 Out of interest, what is your boot.ini at present? If it is partittion(1) that isn't surprising but if it is partition(2) then the partition table has changed.

 If the Data partition is an extended partition, the above doesn't apply. It only applies if Data is a primary partition.

 Brian,

Yes, that is correct. C:=OS, D:=Data, both on the same physical drive. There is a second physical drive with a single primary partition (E:). Both of the hd0 partitions are primary partitions. Checking the current (repaired) boot.ini I see that it is pointing to partition 1,  so based on your thought above, the partition table has not changed.

I understood, from SPT's post earlier in this thread, that after recpveru SPD is supposed check that a system partition is bootable (non-broken) and automagically repair it if necessary. If I'm correct in that understanding, this whole thing is even more curious!

Oh, well...

daveg:

   so based on your thought above, the partition table has not changed.

 

My theory is the partition table was changed at restore time and your repair changed it back. I've no evidence for this. Just a guess.

One of the earlier Acronis True Image builds used to change the partition table at restore time. It caused all sorts of trouble.