Upgrading Guest Additions prevents VM from starting

[alvaro.s]

After migrating my PC from Windows 7 x64 to Windows 10 x64, VirtualBox would not even start. That was fixed by upgrading from 5.0.2 to 5.1.2. So far so good.

My problem is that I have several Windows XP x32 boxes and they just stop working entirely as soon as I upgrade the Guest Additions. Installation goes fine but as soon as I restart the VM I only see a black screen. No matter how many times I restart, I don't even the see VirtualBox POST screen and hitting F12 does nothing. Any idea on how to start diagnostic?

Please find enclosed VBox.log and VBoxHardening.log. (I had the compress the latter to override forum size limits.)

[socratis]

00:00:06.274323 Console: Machine state changed to 'Restoring'

You seem to start from a Saved State. Try to discard it. It's not a good idea to upgrade your (virtual) hardware when the (virtual) computer is "sleeping".

[alvaro.s]

00:00:06.274323 Console: Machine state changed to 'Restoring'

You seem to start from a Saved State. Try to discard it. It's not a good idea to upgrade your (virtual) hardware when the (virtual) computer is "sleeping".

Thanks for your answer. I'm confused with the term "sleeping". I enclosed the log files from the second VM I've tried upgrading, where I had created a snapshot to be sure I could rollback the upgrade. In the first VM I wasn't that cautious and there's no "backup" to restore. (It's a clean XP installation I use as template to clone from.)

So:

1. In first VM there's no Saved State to discard ("Discard" button is disabled).

2. In second VM (attached logs) I can disable saved stated, which rollbacks to snapshot and reverts the upgrade, but issue happens again as soon as I upgrade.

[socratis]

This is a great use for snapshots. But you'll still have to attach a new log, since this one besides the restored state, also ends prematurely because you didn't shut down the VM. So, here is the proper procedure to get a log:

1. Update the guest additions. Do not reboot. Instead shut down the VM.
2. Re-start the VM.
3. Shut down the VM. Not suspended, not paused. Shut down. If you can't shut it down by normal means, close the VM window and select "Power off".
4. Right-click on the VM in the VirtualBox Manager. Select "Show Log..."
5. Save it (just the first log), ZIP it and attach it in your response (see the "Upload attachment" at the bottom of the form).

[alvaro.s]

This is a great use for snapshots. But you'll still have to attach a new log, since this one besides the restored state, also ends prematurely because you didn't shut down the VM. So, here is the proper procedure to get a log

Your checklist was very helpful and led me to realise an error in my initial diagnostic: the problem is not related to updating Guest Additions. What really happens is that my VMs running Windows XP (other OS's are not affected) work under VirtualBox 5.1.2 (they didn't in 5.0.2) if they are already started but they cannot start. So as soon as I halt or restart then I get the black screen.

In any case, please find attached the log I've obtained following your instructions.

[mpack]

The VM is called XP Mode? Where did this XP image originate from? If it really was a Win7 XP mode image then this alone could explain why it fails to start on Win10.

I assume that you upgraded the host OS while the VMs were suspended. So last time these VMs saved state, they had a Win7 host per the XP mode license.

[alvaro.s]

Yuk...

You are right, it was originally the XP Mode image provided by Windows 7. Performance was horrible and I migrated it to VMware and, some time later, to VirtualBox (I figured out it was probably against the EULA but VirtualPC was so frustrating that I decided to walk on the wild side). That was several years ago and I had forgotten about it.

(Yes, I upgraded host to Windows 10 while all VMs where closed and had a saved state.)

[mpack]

No, changing VM platforms wasn't against the EULA, but it was only licensed for use on Win7 Pro hosts and will only remain activated when it detects the correct host. VirtualBox (and I assume VMware) provide the expected API that allows it to detect the host OS, otherwise it wouldn't run at all on those VM platforms.

If you have another XP CD key then you could try installing that, though I frankly don't know if it would work. Google has the details on how to change the Windows product key on XP.