Hello,

Windows XP OS image that was created with Macrium Reflect would crash with Blue Screen of Death with error 0x0000007b

Initially I did made a RAW split-files image of an offline hard-drive utlizing AccessData FTK Imager 4.2.0 and utilized the same application to boot the image; and Windows XP started loading then crashed with BSOD. Reading the other forums I got this explanation:

"means "you are attempting to boot Windows without the appropriate driver for the boot hard disk" (the actual canonical message associated with it is "inaccessible boot device")."

The solution that was proposed, since the operator did convert the RAW image unto VMware .vmdk format, is to use VMWare P2V tool (Physical to Virtual) to 'convert' the image into a more of a bootable type .vmdk.

When I created a Macrium Reflect image of the offline hard-drive (Windows XP OS boot hard drive), and tried to boot the OS via viBoot, the same issue happened, and Windows XP started loading and then crashed with BSOD and with the same error. 

I understand viBoot utilizes Microsoft's Hyper-V; is there any way I can have a better compatibility in booting the Imaged OS with viBoot ?

Beside the driver issues most likely causing the BSOD; how can I tell which version of Microsoft Windows XP is the image?  Is there a file I can read or open within the imaged OS, if I do mount it as an online Hard Dive, that will tell me if:
1- OS is Windows XP Home Edition, or Pro (Professional), or is it on x32 or x64 architecture.
2- Amount of RAM or CPU core that the OS was running from (if that makes a difference).

Thanx

Typically just capturing an image of a Windows environment that was set up to run on physical hardware and trying to boot it in a VM environment will result in Windows failing to boot, because the Windows environment will be set up to expect (and load drivers for) a completely different set of hardware than will be present (virtually) from the hypervisor.  Transplanting a hard drive containing a Windows installation from one PC into another will also typically result in Windows not booting for the same reason.  That's why for the latter scenario, Reflect includes a ReDeploy wizard specifically designed to tweak a Windows environment to allow it to boot on dissimilar hardware, which is often used when restoring an image from one PC onto another one.  viBoot does something similar because the same need exists in that scenario.  In addition to allowing Hyper-V to use Reflect images as virtual disks, viBoot tweaks the image (non-destructively, by applying changes in a separate file) to basically ReDeploy it for running within a Hyper-V environment.  Or at least that's what's supposed to happen.

If you encountered the same BSoD even when using a Reflect image as your source and using viBoot, I'm not sure what would account for that.  There might be a "viBoot ReDeploy" log that Macrium Support can get from you to shed light on the issue, though.  As for finding information about the Windows environment while it's offline, that MIGHT exist somewhere in the registry, and it is possible to mount an offline registry hive file in Registry Editor when you've got an offline Windows partition available, but I'm not sure where you'd look.  That said, out of the items you mentioned, the only possible item I can see being relevant would be whether it's 32-bit or 64-bit, simply because Windows XP 64-bit wasn't very widely used or supported via drivers, so it's possible that viBoot would have trouble with ReDeploying for that OS -- but I'm not certain about that.

Still, I do find it interesting that you encountered this same issue even when using other tools that are meant to allow P2V, including making the necessary changes to achieve that.