Recreate the partitions manually then perform manual restores of each image (fail)
Some will know this but others won’t. Sometimes when you move a HD or do restores the MBR or partition info can conflict in the new system BIOS and the above commands in method 3 won’t work. When you do a system restore it recreates the partitions and statistics exactly as they were from the old system so I decided to start with a fresh unpartitioned drive and then create the partitions manually. This would eliminate any conflicts with the BIOS.
A Windows 7 installation creates two partitions on your drive. One is the system partition which contains the boot image (files) and is about 100MB and the other is the OS image which is usually the C drive and contains the remainder of the space on the drive. In this method I created two partitions of 200 MB and 100GB. Then I ran the wbadmin (windows backup command line tool) to restore the images to these partitions.
One very important thing I learnt which will possibly have you banging your head against the wall is that the GUI you get to restore the PC when you are in the Windows RE (recovery environment) only allows you to do a FULL COMPLETE system recovery. It will format the drive, recreate partitions and restore all drives that are needed for the OS to run. This is important to note because if you want create partitions manually and restore the images separately there is no GUI to do this. The GUI in the RE is a scaled down version of the one in the actual OS when it has loaded correctly. To do a restore any other way in the RE you must use Wbadmin.exe so get learing 😉
Wbadmin itself is a nightmare to use if you don’t know how to and it deserves it’s own article. Eventually I figured out how to use it all and now I am quite comfortable with it. I restored each image and then ran the commands in method 3 to rebuild the boot menu and fix boot sectors etc. I confirmed that the partitions where now as I created (200MB and 100GB rather than their backup equivalents) and rebooted.
I got a different error and found that the boot/system partition was not set to active. This is because the restore didn’t create the partitions so it didn’t set this partition to ACTIVE. I loaded up the RE again and set the partition to active. I rebooted and again the same stop 0x0000007b so this method also failed!!
If you wish to learn a bit more about how to create the correct partitions needed for this look here http://technet.microsoft.com/en-us/library/dd349348%28WS.10%29.aspx#BKMK_1. This MS doc is a step by step guide to using answer files and deploying an image but it contains the info about the partitions. Scroll down to point 3 and in there it tells you the settings you need to use when creating the partitions (about half way down the table).
Try to trigger sysprep or force a scan hardware command on boot up (fail)
I already knew the stop 0x0000007b was relating to drivers but now I came to the conclusion that it must be the motherboard drivers. Don’t quote me on this one but I am guessing that if it was a mass storage driver then Windows would automatically install this on bootup like it does with any other hard drive you install. This rules out it being a mass storage driver issue. This is why I think it was the motherboard. I looked everywhere but you cannot force it to do a hardware scan at bootup and sysprep can only be ran once the OS had loaded which indirectly forces the PC to scan for hardware.
Load the backup VHD image in Hyper-V and see if that works (almost, getting closer…!)
By now I finally accepted that it wasn’t going to work directly on the new hardware. I still to this day do not know the exact cause of it but I know tried everything I could possibly think of. Obviously with it being hardware related we can bypass this by using Hyper-V so thought I’d try that.
NOTE: This also allowed me to test another theory. I guessed that the VHD that was made from the backup should (in theory) just boot in Hyper-V. What I mean by this it that it isn’t documented anywhere as to whether the VHD produced from a backup is the same as VHD produced using Hyper-V or Native Boot. For all you know they may have some subtle differences.
As I keep repeating you all know by now a Windows 7 install creates 2 partitions. The backup creates two separate VHD’s for each partition not one VHD with both partitions in. I created a new VM and attached both of these drives and had to set the boot partition as active and run the same commands above in Method 3 to repair boot menus etc. I no longer got the stop 0x0000007b because it wasn’t getting even that far now. It would not load the boot image at all.
The only difference I could spot between a VM created from scratch and my set up is the VM has ONE VHD which contains all partitions whereas I had the two partitions split into two VHD’s. Obviously a lot stuff happens with the boot image which I can’t possibly understand and we know that the complex stuff happens here so there may be other things that affect it also.
By this point I had learnt a lot about how Windows boots as you can imagine… If you have read all the above you should have learnt a lot as well and I realised that to load the OS all you need is a working boot image which points to the correct winload.exe on the OS partition(you can see this in bcdedit). Knowing this we can assume that all the fancy, complicated stuff is handled with the boot image and the OS image is really just like a data drive and nothing complex happens on this drive. I thought, hmmm…what if I use a boot image I have created in Hyper-V that I know works and tell this boot loader to load my OS VHD instead…