Recently took an image of a Windows 7 machine that had checkpoint installed (Used our fancy new forensic duplicator device which took approx 2 hours to export a 320GB drive to an E01 format D ). This is just for internal testing purposes so I have the required details to login past Checkpoint.
I've tried using Encase to emulate the disk and then add this to a new vm as a physical disk. I’ve tried using FTK to export this from an E01 to DD format and then using LiveView to create the vmdk config, but the same thing always happens. The vm boots up, prompts me with the Checkpoint login screen, I type this in, all looks good, Windows starts up but then it blue screens on me.
I've also tried running Checkpoint's mount utility to decrypt the drive and run a chkdsk on the partition. Same thing, BSOD! Given that the vm initially boots into Windows, I think it may have something to do with the SATA operation mode configured previously on the laptop (set to Raid On mode).
Has anyone had any success in taking an image of a windows machine loaded with Checkpoint and running this on a vm? Or any ideas as to what might be going wrong?
Just for the record, there is no such thing as "a" BSOD, there are tens of different BSOD's each with a STOP ERROR CODE, which is VERY relevant.
If you are having a STOP 0x0000007b, then yes, it is "inaccessible boot device", which basically means that the install is missing a driver for the hard disk controller.
If this is the case, it seems to me like the checkpoint is not the "main" issue, but the procedure (that you did not detail) you used for going P2V (Physical to Virtual) having an hiccup of some kind.
If you prefer, since you are doing tests, try doing another image of that machine but without Checkpoint installed, likely you will have the same BSOD 0x0000007b.
jaclaz
Thanks for the feedback. It's my first post so apologies for the vagueness, will keep that in mind next time.
In regards to the P2V process, I basically used a software tool called LiveView which creates a virtual machine out of a raw (dd-style) disk image. If there were a hiccup with the P2V process, I don't think I'd have gotten past the boot stage when running the newly created vm.
You're absolutely correct, I am getting an inaccessible boot error. I think this is where the issue lies. Further testing needs to be done on my part. As suggested I'll start off by doing another image of that machine without Checkpoint. If I still get a STOP 0x0000007b error, at least I know its nothing to do with Checkpoint.
I'll post my findings as soon as the tests are complete.
I've tried using Encase to emulate the disk and then add this to a new vm as a physical disk. I’ve tried using FTK to export this from an E01 to DD format and then using LiveView to create the vmdk config, but the same thing always happens. The vm boots up, prompts me with the Checkpoint login screen, I type this in, all looks good, Windows starts up but then it blue screens on me.
What version Checkpoint/PointSec? What version VMWare? Did you try something else than EnCase emulation – say, FTK Imager or MountPoint Pro or …
We've had mixed success – I've never got past the stage where you are myself, while I've seen reports that other are able to do it. Never figured out exactly why, though. Restoring the image to a new disk, and booting that has never been a problem – I suspect some VMWare emulation details.
There's a pretty good KB article (KB314082) that you may be interested in examining.
I suspect that LiveView may have problems adjusting the registry PnP information about hardware conrollers if it can't get past the encryption layer.
If there were a hiccup with the P2V process, I don't think I'd have gotten past the boot stage when running the newly created vm.
No.
Meaning that the 0x0000007b means "inaccessible boot device" AND it happens while booting, in the exact moment the "switch" is performed.
This can be caused by a few things, BUT in 99.99% of cases it is a missing (or badly configured in the Registry) hard disk controller driver.
When a NT based system boots, there is a "switch" during booting between "real mode" and "protected mode".
Basically the "real mode" uses "standard" drivers and BIOS services, while, when the "switch" is made, the hardware is re-scanned and the appropriate and needed drivers are loaded (if present/installed correctly).
The issue with P2V is that a tool like LiveView should automatically check (and fix) the issue, BUT in some cases it simply fails to do so.
The "target" of LiveView is a VMware virtual machine, such a virtual machine NEEDS a specific driver for the hard disk, there could be an issue in the actual .vmx file
http//
but more probably (for *any* reason) the settings in the Registry need to be "fixed".
A (relatively quick) way to verify (IF checkpoint is found to be unrelated) could be trying (for test) another P2V program, such as
http//
Or do a manual "conversion", as an example, using as target Qemu (as opposed to VmWare) would allow to use the "standard" IDE drivers.
Or - still in the VmWare approach - you can manually add the relevant Registry keys (and/or check the ones you have right now)
http//
jaclaz
99.99% of cases it is a missing (or badly configured in the Registry) hard disk controller driver.
Spot on jaclaz, I've managed to get the vm to run by editing the following registry settings
The mistake I made was to assume Checkpoint was the cause for the Inaccessible boot device error. Even if Checkpoint were not installed, the vm would still have failed (tested this on an image without checkpoint and would still get a STOP 0x0000007b error). In fact, the only obstacle to Checkpoint in my case was in decrypting the partition so as to make the necessary registry changes (which I managed to do by booting the vm into a WinPE boot disk pre-installed with Checkpoint's disk mount utility).
I'm happy to document the steps taken in further detail if anyone thinks this would be useful to them.
Thank you to all for your replies, much appreciated.
I'm happy to document the steps taken in further detail if anyone thinks this would be useful to them.
That would be nice, though the solution you found is *somewhat* a "specific" one and needs (before the details) some further info/explanation.
The given link basically implies that the "source" physical machine had not a "plain IDE" hard disk controller driver and that LiveView creates a "plain" IDE image, i.e. something with this
http//
ide00.present = "TRUE"
ide00.deviceType = "disk"
ide00.filename = "aunt-lindas-favorite-sausage-ide00.vmdk"
which is a "special case" Virtual Machine, as "standard" VMware VM's use the SCSI (LSI) media connection, as in
http//
Such an "IDE based" virtual machine will use a "standard" driver, such as the pciide (but the intelide driver should be compatible), which corresponds to the "Standard Dual Channel PCI IDE Controller".
BUT the image for whatever reasons fails loads the intelide.sys driver or the pciide.sys (this is probably the "hiccup" in the LiveView P2V, failing to set correctly the Start parameter for either of these drivers).
In other cases this may be not needed at all or setting to 0 another driver start may be required.
The *somewhat* more "generic" approach is to set ALL those drivers start value to 0, see
http//
and let Windows 7 solve the issue "automagically" (but still it won't most probably work for *all* possible scenarios).
In theory a driver with Start 0 will attempt loading, then, NOT finding the hardware that it should drive, should quickly UNload, but in practice a conflict of *some* kind may arise.
I hope the above makes sense.
For the record, "automatic" tools such as this one (XP/2003 ONLY)
http//
do exist, cannot say specifically for 7.
jaclaz