virtualbox.org

I know 3D acceleration is useless in this condition, but I guess it should not crash the VM.

Environment: Ubuntu 14.04 + Virtualbox 5.2.10 + Windows 10 Guest

00:00:09.215266 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Failed to load unit 'vga' (VERR_SSM_LOADED_TOO_MUCH)}, preserve=false aResultDetail=0
00:00:09.215343 Power up failed (vrc=VERR_SSM_LOADED_TOO_MUCH, rc=NS_ERROR_FAILURE (0X80004005))

Full Log is attached.

00:00:00.075968 Console: Machine state changed to 'Restoring'
...
00:00:08.810182 VMSetError: /home/vbox/vbox-5.2.10/src/VBox/VMM/VMMR3/SSM.cpp(8707) int ssmR3LoadExecV2(PVM, PSSMHANDLE); rc=VERR_SSM_LOADED_TOO_MUCH
00:00:08.810184 VMSetError: Failed to load unit 'vga'
...
00:00:08.954237 Changing the VM state from 'LOADING' to 'LOAD_FAILURE'
00:00:08.954292 Changing the VM state from 'LOAD_FAILURE' to 'POWERING_OFF'

It's not a "crash" per se, VirtualBox seems to know that something went wrong, and it shuts down the whole operation. My guess in order to prevent further corruption.

• Does it happen at startup as well, or only when Restoring from a Saved State?
• Was the Saved State from the same version of VirtualBox, or you saved the VM, upgraded VirtualBox and then you restored the VM?
• Is this reproducible?
• If yes, can you give us a step-by-step scenario?

A pure start(not resume) in headless will also cause VM abort.

Attach the log for your information.

Since the crash point is during Windows boot/resume, it may also be some guest specific problem.

This is currently 100% reproducible on my environment.

If I checked 2D/3D acceleration and try to boot/resume it headless/deattachable, the VM always crash.
If I unchecked them, the VM will run normally.

A detailed reproduce steps cannot be given since it would requires clean install of VirtualBox/Windows Guest, I will update if I bother to do this.

On the first pass, I didn't notice something that really differentiates your Win10 from the "typical" installation:

00:00:00.167458 [/Devices/efi/0/] (level 3)
00:00:00.167459   Trusted <integer> = 0x0000000000000001 (1)

You're using EFI! I don't know why you did that, but I'm installing a Win10 1709 guest now in EFI mode, to see if I can replicate what you're seeing.

The other suspect that I have, is your graphics card/drivers:

00:00:00.163438 OpenGL Info: Render SPU: GL_VENDOR:   Intel Open Source Technology Center
00:00:00.163460 OpenGL Info: Render SPU: GL_RENDERER: Mesa DRI Intel(R) Haswell Desktop 
00:00:00.163463 OpenGL Info: Render SPU: GL_VERSION:  3.0 Mesa 11.2.0

Intel is not exactly known as the most solid software producer in the world. Their software actually is known to be a ... ah, never mind, I promised I wouldn't be swearing in public.

Any chances of updating that? Is it the "latest and greatest"™ that they offer? Any remote chance of trying a different GPU?

BTW, does the same VM start "normal"? Can you double-check?

socratis wrote:BTW, does the same VM start "normal"? Can you double-check?

Yes, "normal start" is always good.

I talked to the developers about the fact that VBoxHeadess crashing, while normal works (usually it's the other way around) without mentioning any details about your specific setup. Somebody mentioned:

Well, the only possibility I can see something like that happening, is if someone does something really stupid like enabling 3D acceleration for a headless VM.

Nailed it!

So, to paraphrase their diagnosis, do not enable 3D acceleration. You may be right, it shouldn't crash, but I guess if a known workaround exists, the priority of addressing this are not that high (if you know what I mean).

Hi,

I've got a broken arm so couldn't get back soon.

Thank you for confirmation again.

Regards,
priv

priv wrote:I've got a broken arm so couldn't get back soon.

Yikes, I know the feeling!
Hope you are back up and running soon...