Startup crash in VirtualBox VM but VMWare is OK

[MartinHowe]

Starting GZDoom in an Oracle VirtualBox 7 VM crashes. This works, albeit slowly, in a VMWare 16 Player VM. It's only used for development so speed of play isn't critical. I have to use a VM as I don't have (and no longer trust) bare metal Windows PCs and use Linux (with self-built GZDoom) for everything else. I realise that this is an odd use case, but would at least expect it to exit with (e.g.) "OpenGL version too low" (or something like that) rather than just crash. The current music track (D_INTRO) continues to play to completion as long as the crash report window is open. I used a DRD Team nightly build to do this but it also happens with the current release version of GZDoom downloaded from ZDoom.org.

Steps to reproduce:

Download this nightly build from DRDTeam.
Extract to a folder
Copy doom2.wad into the folder
Note there is no .ini file present
Start GZDoom by double clicking

Expected result: GZDoom either works correctly or aborts with a normal error dialog
Actual result: GZDoom crashes and shows the crash report dialog

Crash report: https://www.dropbox.com/s/pgcb07lkwm2d5 ... t.zip?dl=0

[Graf Zahl]

please be aware that I do not use VM software so I won't be able to help you here. This sounds like the system reports some feature that isn't actually present. The crash happens outside GZDoom inside VirtualBox so the chance is low to track this down.

[Rachael]

This crashes in the VBoxGL.dll driver - there's nothing we can do here.

We do not support running within virtual environments. The very most you should ever attempt when running GZDoom is using Wine but that's for testing only. (Or in one instance I recommended that to a person who was using SteamOS because it was missing FluidSynth)

If it really matters to you, you can try and contact the VirtualBox developers about this issue, but whatever the case may be, currently GZDoom is attempting to access OpenGL features which are not yet available in a VirtualBox environment, and that's why it is not working.

VirtualBox complicates things even further because it attempts to brute-force its DirectX wrapper drivers (that route system DirectX calls to the GL driver) over the Windows-provided drivers, instead of properly using ICD's like a normal display driver vendor would and should do.

So - sorry - I am closing this one. This ball is not in our court. Please contact the VirtualBox authors about this instead.

[MartinHowe]

Thanks Rachel and Graf Zahl I thought it was very likely something like that; VirtualBox reporting a missing feature as present sounds about right.

This isn't mission critical, I can just use VMWare as before; only tried VirtualBox as the new version supposedly had better 3D graphics support but I was sceptical about them getting it right ... and it seems with good reason

Just going off to uninstall VirtualBox and delete the VM, then all will be well