I don't know how many times you've seen 0x0000007b when your Windows XP dies in a solemn blue. I've certainly seen my share. This article is only meant to discuss a specific condition that caused it: disk cloning. This is the time that you aren't careful enough to use a more capable tool, such as Acronis' TI with Universal Restore, so your newly imaged system falls flat on a different hard drive controller. This could also happen if you just physically attach a hard drive to a different computer that has a different HD controller. Microsoft has a very good KB article
explaining how you can preempt (to a degree) this kind of problem BEFORE you clone or migrate.
So what if you weren't that careful? You forgot to take precautions, and you didn't use the right tool. Sometimes you don't want to, or simply unable to go back and try again (say your source machine is gone for good). All is not lost. You don't necessarily have to go through a lengthy repair installation, which will surely fix things in most cases.
Try MS KB307545
. All you need to do is drop into Recovery Console and copy the system
hive file under Repair
directory to replace the one in System32/config
, which is used by the system to boot and run things.
I'm not entirely sure why that would help in this scenario. My theory is that the repair
copy of system
, which was saved at install time, is a more "generic" version for things from HAL layer on down. Using it Windows XP would be able to survive more device structures and boot up. I can give one example this saved me time. I was doing P2V (physical to virtual) from an old TIB image (Acronis) to VMWare Server 2, using VMWare Converter 4. This trick let me get past 0x0000007b without repair installing XP.