Win7x64 BSOD 0x7B - inaccessible boot device

[Ngarara]

I’m trying to virtualise a Fujitsu Lifebook E744 running Windows 7 x64, and run it under Fusion 7.1 on my 2011 MacBook Pro quad-core running MacOS 10.10.1.  I had to create the VM image using Fusion 6.0.4  on a MacBook 2008 because the PC Migration Assistant does not recognise Fusion 7.1 (fails with a version mismatch).  On both MacBooks, i.e. Fusion 6.0.4 with VM hardware version 10, and Fusion 7.1 with VM hardware version 11, the VM gives a BSOD during boot:

*** STOP: 0x0000007B

This indicates that the boot device was not accessible.  I have looked at a lot of VMware forum posts and searched on the ‘Net, and the majority of advice suggests that there is a problem with the LSI Logic virtual SCSI driver - it’s missing, it’s not being loaded, or Fusion isn’t configured to use it.

However, I’ve been through the Startup Repair console, looked at the Registry, checked the system32 directory, and looked at the .vmx and .vmdk files in the VM package.  As far as I can see, both the VM image and Windows seem to be correctly configured, as follows:

.vmx file:

scsi0.present = "TRUE"

scsi0.virtualDev = "lsisas1068"

scsi0.pciSlotNumber = "160"

scsi0.sasWWID = "50 05 05 64 c3 0c 4c 20"

scsi0:0.present = "TRUE"

scsi0:0.fileName = "Windows 7 x64.vmdk"

scsi0:0.redo = ""

bios.bootOrder = "HDD"

bios.hddOrder = "scsi0:0"

floppy0.present = "FALSE"

ide0:1.present = "FALSE"

sata0:0.present = "FALSE"

.vmdk file:

ddb.adapterType = "lsilogic"

Registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LSI_SAS: Start = 0

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\msahci: Start = 3

(I’ve also tried the latter with Start = 0)

C:/Windows/system32/drivers contains the driver lsi_sas.sys, so it’s not a missing file.

Does anyone have any suggestions for things to check/try?

[Ngarara]

Something I've noticed during further investigation: when running in Startup Repair mode, the system disk appears to be X:, i.e. the command prompt is X:\windows\system32\> .  There is no C: drive, but there is a D: drive which appears to be my Windows .vmdk.  Is that normal for Startup Repair, or could it indicate that my disk is being incorrectly mounted as D: rather than C: ?  I've never dealt with Startup Repair before, so I don't know what constitutes 'normal' behaviour.

Message was edited by: Ngarara - correct System Restore to Startup Repair

[Ngarara]

Could someone out there throw me a bone and confirm that the settings described above look normal for Win7x64?  In particular, the odd drive letter situation (the vmdk is D:, not C:) when in Startup Repair.  This could be something very simple, but I'm flying blind...

[WoodyZ]

Ngarara wrote: I’m trying to virtualise a Fujitsu Lifebook E744 running Windows 7 x64

OEM versions of Windows 7 are not virtualizable by its EULA and therefore no help may be provided in this use case scenario as it would violate the VMware Community Terms of Use to do so.

[Ngarara]

It's not an OEM build - and I work for Fujitsu.  The company has a massive corporate Microsoft licensing scheme, so that is not an issue.

[ColoradoMarmot]

Don't.  Converting physical machines always results in bloated, buggy, unstable VM.  Since you have legal licenses, build one from scratch.

[Ngarara]

dlhotka, appreciate the advice, but this is how I need to do it.

What I need is confirmation that the settings described are as they should be.  I'm assuming some member of this forum has a working Win7x64 image and can give me that information.  So far, all I'm being told is that I'm not allowed to do it or that I shouldn't, which isn't really helping...

[WoodyZ]

So far, all I'm being told is that I'm not allowed to do it or that I shouldn't, which isn't really helping...

Since the FUJITSU Notebook LIFEBOOK E744 ships/shipped with Windows 7/8 and so it was logical to assume it was an OEM Install in the absents of what most typical corporate users of volume licensed versions will mention, which you of course didn't until you replied to what I had said.  Additionally the advice given by dlhotka is sound advice and I too stand by it.

What I need is confirmation that the settings described are as they should be.  I'm assuming some member of this forum has a working Win7x64 image and can give me that information.

That said, as far as any settings for a Windows 7, or any other OS, all one need to do is create any given OS Virtual Machine without installing the OS to see what the normal defaults are for comparison and or validation of what you have.  It's not rocket science! :smileywink:

Personally I would not use the VMware Fusion built-in Migration Assistant and instead use VMware vCenter Converter Standalone and validate the settings prior the the actual creation of the Virtual Machine.

[Ngarara]

Since the FUJITSU Notebook LIFEBOOK E744 ships/shipped with Windows 7/8 and so it was logical to assume it was an OEM Install in the absents of what most typical corporate users of volume licensed versions will mention, which you of course didn't until you replied to what I had said.  Additionally the advice given by dlhotka is sound advice and I too stand by it.

Fair comment.  Unfortunately, the purpose of this is to be able to virtualise an existing machine, so building one from the ground up doesn't meet the need.  It may be a better approach, but it's not the one I require.

That said, as far as any settings for a Windows 7, or any other OS, all one need to do is create any given OS Virtual Machine without installing the OS to see what the normal defaults are for comparison and or validation of what you have.  It's not rocket science! :smileywink:

Now that's a damn good idea!  I'll try that & see if I can spot any differences.

Personally I would not use the VMware Fusion built-in Migration Assistant and instead use VMware vCenter Converter Standalone and validate the settings prior the the actual creation of the Virtual Machine.

The problem there is that the source machine has BeCrypt FDE in place, which includes mandatory encryption of any USB-attached drive.  BeCrypt is invisible to the Migration Assistant - the Assistant can still create working VMs (I've done it before from BeCrypted sources), they just don't have FDE.  However, If I create the VM image on the source machine using the standalone converter, it's tricky to get the image off - if I stick it on an external drive, the drive will be encrypted & unreadable on the target machine.  I'll give it a try; at least I can compare the two images, and I can probably upload the standalone version to a server & get at it that way.

Thanks - now I have some avenues to explore. :smileyhappy:

[WoodyZ]

As far as creating a Virtual Machine to compare keep in mind the following.  Do not create the Virtual Machine using Easy Install and instead select More options... > Create a custom virtual machine > Continue > selecting the correct OS and from that point forward just accept the defaults.

At this point the .vmx configuration file will not contain all of the options as the one that has already been run, so you'll want to start the newly create Virtual Machine and then shut it down.  The .vmx configuration file will now contain the various options that only exist after first run.  Now the comparison will be more accurate.

As to using VMware vCenter Converter Standalone you can direct the Destination to be on the Network and not use the attached USB Drive.  That said however I'd opt for attaching the USB Drive if it's a USB 3.0 and on a USB 3.0 Bus and then once created copy the VM via the Network to the its final destination and then once done with the USB Drive wipe it out and repartition and format on a system not using encryption.  Whenever possible, I just try not to create and send to a Network location while it's being created as any hiccup in transmission has the potential corrupt the image causing one to start all over.

[Ngarara]

OK, 2 steps forward, 2 steps back.

I created a blank VM, and compared the two vmx files.  Not a great deal of help, unfortunately; both images have the same SCSI settings.  The rest of the differences didn't look relevant (mainly due to the default machine using SATA for the CD drive while the migrated one uses IDE).

Next move was trying the standalone VMware Converter on the source machine.  Which completed successfully; after which I had quite a few problems trying to get the image uploaded to my Time Capsule and then downloaded again to my MacBook.  However, when I booted the standalone image in Fusion, I got exactly the same problem as with the migrated machine.

But one thing the standalone converter alerted me to: the drive in the target machine is an SSD/HDD hybrid.  So there are actually two drives: the obvious C: drive, and some sort of 'phantom' drive which I assume is the SSD element.  I believe that is why, in the System Recovery console, I can see an X:, a C: and a D: drive.

The X: drive is "Boot" and has the following:

$WIMDESC

<DIR>ProgramData

<DIR>Program Files

<DIR>sources

<DIR>Users

<DIR>Windows

The C: drive is "System" and only has the following files (all Hidden):

ACTIVE.MDT

<DIR>Boot

bootmgr

<DIR>System Volume Information

The D: drive is "OSDisk" and has:

<DIR>$Recycle.Bin

<JUNCTION>Documents and Settings [C:\Users]

hiberfil.sys

<DIR>Intel

<DIR>MSOCache

pagefile.sys

<DIR>Perflogs

<DIR>ProgramData

<DIR>Program Files

<DIR>Program Files (x86)

<DIR>Recovery

<DIR>System Volume Information

<DIR>Users

<DIR>Windows

I have no idea how all this cack interrelates.  On the surface of it, none of these disks has a complete set of software.  How on earth the boot sequence is supposed to work, I can only guess.

On the source machine, there's just a C: drive visible.  I'm assuming something is faking things so that a single drive is being displayed, but it's actually a Frankenstein creation, all stitched together.

Therefore: has anyone else ever tried to virtualise a machine with one of these hybrid nightmares?  And how did you make it work?