source disk registry damaged after cloning with true image 2011
The following happend twice now, with different source and target disks, I believe it to be a bug in acronis true image 2011:
After succesfully cloning the main drive of a PC, the cloned SOURCE drive has a corrupted registry and refuses to boot.
The OS was windows 2003, and the system was not shutdown but in hibernation while the disk was cloned, which I believe to be part of the reason for this error.
Here are the detailed steps necessary to reproduce the error:
- After sending windows to hibernation I cloned the source harddrive containing the OS with the acronis true image 2011 boot cd.
- I disconnected the newly cloned backup harddrive, and resumed the os from hibernation.
- so the system is still running from the source drive, and since the target backup drive is not connected nothing should have changed.
- However, now bugs started to show up: random crashes and freezes, bluescreens
(e.g. STOP 0x0000008E (0xC0000005,...))
chkdsk revealead one error in the partition table, after fixing that, windows refused to boot
"Windows 2003 could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SYSTEM"
- checking the drive in a different pc reveals the registry hive file "WINDOWS\SYSTEM32\CONFIG\SYSTEM" has a size of 0 bytes.
- Copying the system hive from a backup fixes the problem. Presumably using the "Last Known Good" system restore option would fix it on windows XP too, however that is not applicable to windows 2003.
I strongly suspect that acronis true image changed something in the registry while cloning the drive. Since the system was in hibernation, parts of the registry where still chached in memory, so the registry ended up in an inconsistent state.
Can someone confirm or dispute that acronis true image performs any write access to the source drive during a cloning?
Has anyone else had a similar problem? Is this a known bug?
Are there other possible reasons for this bug? I can almost definitely rule out hard drive damage, since the bug appeared with two sets of unrelated drives, always directly after the cloning, and the drives performed fine afterwards
As you can see I was able to make many successful clones using this product and then, for unknown reasons, the process of cloning started to alter the system hive file.
I am still baffled as to why this would occur.
Nice bump for a year old thread Irv :-)
Clone works, it is not the issue. It can damage the source and the destination and this damage might not be recoverable. The damage can occur because of hardware, power or user issues (for example, many users reboot with both disks in the computer, or clone the wrong source on the wrong destination, etc.).
Once you have done a backup however, you can take the source out of the system and avoid any damage afterwards.
Many users still prefer to use clone, go figure...
Clone is very useful when there is no place/time to store a backup, but it should be a last restore function, IMO.