VMs won't load after upgrading 4.2.4-81684 to 4.3.18-96516

[gjcdeluxe]

Rt. click the guest in the main manager then show log. Save and post as an attachment.

OK, here's a log from an XP guest that won't boot after upgrading.

[mpack]

@gjcdeluxe: You are suffering one of the known "hardening" issues and probably need to downgrade to 4.3.12.

p.s. You don't give 4GB to a 32bit VM - it makes it a 64bit VM. 1GB is way more than enough for XP, and I wouldn't give more than 2GB.

It's unfortunate that Doveman1 hijacked this topic as his problem doesn't resemble yours at all.

[daniel15092]

Can't remember which one I downloaded (the logs) but I noticed this error:

03:04:03.045711 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={The object is not ready}, preserve=false

Something is up with the COM Object, Its not ready for some reason, and what ever its trying to access, it can't, Try this:

1. Right click on VirtualBox on the start menu/Desktop
2.Run as Administrator
3. See if the same thing happens, I suspect it cannot Access something because its not being ran as Administrator

[gjcdeluxe]

@gjcdeluxe: You are suffering one of the known "hardening" issues and probably need to downgrade to 4.3.12.

p.s. You don't give 4GB to a 32bit VM - it makes it a 64bit VM. 1GB is way more than enough for XP, and I wouldn't give more than 2GB.

Great, yes that has indeed solved it Thanks for your help! And yes I probably went overboard on the RAM allocation for XP, though fwiw it has been utilising 3931MB without a hitch (ie that's the amount reported in the XP guest when 4GB was allocated).

[gjcdeluxe]

Hmm spoke too soon. My saved snapshot was running fine after switching to 4.3.12, but as soon as the VM is rebooted, it bluescreens with an error about insufficient disk space (even though there is 1GB free in the VM's hard drive, and a fixed size pagefile... 512MB IIRC). Upgrading the guest addiitions, clearing out more space on the VHD, and reducing the RAM to 1GB haven't helped, though I am able to boot XP in safe mode. Reverting to VirtualBox 4.2.4 solves it.

I also get the ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={The object is not ready}, preserve=false error in the log, but running virtualbox as administrator makes no difference.

[mpack]

Make sure you revert the GAs to 4.3.12 as well.

[gjcdeluxe]

Yes, the guest additions are v4.3.12. Strangely, my other XP VM is not having this problem.

[mpack]

If you Google for that stop code you'll see that it's caused by a driver crash. It's impossible for me to diagnose which driver is involved from here. Are you saying this VM starts up ok but BSOD's on a reboot?

[gjcdeluxe]

Hi, yes the VM behaves fine when resuming from a snapshot of the running system, but upon restarting windows I get the bluescreen.

[mpack]

Just to be clear, you can't "resume from a snapshot". Do you mean a saved state? If yes then I hope you discarded all saved states when (or before) you downgraded to 4.3.12. Personally I would be wary about any version changes when using this feature, however the official position is that forwards compatibility is supported, but you can't go backwards without invalidating the saved state.

[gjcdeluxe]

Ok perhaps there has been a change in terminology since vbox 4.2.4, but this version refers to these saved states as snapshots (Host+T = "Take Snapshot") and I am able to start the VM by restoring them, but the VM crashes when rebooting the guest OS. The saved states/snapshots were created in 4.2.4 and there is no trace of anything to do with 4.3.18 as I completely rolled back the host system (back to vbox 4.2.4), then upgraded to 4.3.12.

[mpack]

No, snapshots and saved states have never meant the same thing, those are two entirely separate features. Nor has the terminology ever changed.

A snapshot is like a restore point in windows: so you can see that "resuming from the last restore point" probably isn't what you mean. If all you did was start a VM that happens to use snapshots then it was just a normal start of a VM... unless that VM happens to use saved states as well. Snapshots don't care about VirtualBox version changes, but saved states might.

Another way to look at it: a snapshot (restore point) preserves a previous state of the VM's disk drive. That previous state is available for manual recall forever, or until you delete it. A saved state is just a dump of the RAM of a running VM. The VM can quickly be restored to the same running state by reloading RAM from the saved state file. Once reloaded the VM continues and the saved state is deleted.

[Perryg]

I look at "saved state" as hibernation. Even then if the guest was in a "saved state" during an upgrade you run the risk of it not starting after without discarding the "saved state".

I also do not hold confidence that a snapshot will always work after an upgrade since the host code does change and the guest may be looking for something specific from the previous version. Not that it can't be repaired but I have seen it fail. Yet another reason I don't use snapshots.

Another issue with waining so long between updates especial during a version change that is not maintenance you don't really know where to start to find the problem/s.

[gjcdeluxe]

Then I do indeed mean snapshot, as I have been restoring to a snapshotted state prior to starting the VM. This was a P2V XP system, so I'll try building a new VM from scratch in 4.3.12 and mounting the old VHD in its original state from when it was cloned from the physical system.

update:
still crashes in 4.3.12 after creating a new vm from the same P2V system that was virtualised successfully under 4.2.4

[mpack]

Well, if it's a P2V then that likely explains the driver crash. You'll have to do some detective work to see what driver is involved. Restoring to a snapshot state probably isn't helping either, since XP is supposed to have self repair for this sort of thing (the driver should eventually be disabled, if you weren't wiping the slate clean on every boot!).