Virtual Machine Freezes after host desktop switched

[Alex Tidmarsh]

I have a Windows 2000 VM running under VirtualBox 6.0.6 r130049 (Qt5.6.2)

This is upon a fully up-to-date Windows 7 Ultimate host machine, using a tool called Dexpot to switch host desktops upon a three-monitor system.

When I switch back to the desktop upon which the previously functional and running VM is displayed, the VM is locked up. The only way to recover it is to pause and snapshot the VM, close it and then start it up again (not always successful in such cases).

As I have been using Dexpot for some years and can definitely say that the only software on the host affected by this problem (out of literally hundreds of software engineering tools, including VMWare, and office applications) is VirtualBox.

Is this a known problem and can it be fixed?

[Alex Tidmarsh]

Incidentally, the Guest additions on the VM are the ones matched to this VirtualBox release (6.0.6).

[Alex Tidmarsh]

As an additional test, I have tried the same procedure with a "DOS6.22-Windows2.03" VM. Therefore the Guest editions (which are not present on this VM) are eliminated from being the culprit. This is definitely a problem with VirtualBox itself.

[Alex Tidmarsh]

Furthermore, (as a work-around), if I minimize the VM's display before doing a host desktop switch, then the problem does not occur.

Therefore it appears to be something to do with the actively ongoing display output to the HOST's screen, rather than the VM's virtualized screen.

It also does not happen if the VM is showing in a "Windowed" mode rather than "Full-screen". So it turns out that somehow minimizing (hiding) the VM display and then restoring it can also "unlock" the VM again - but I'm uncertain if this is always guaranteed either.

However, in "Seamless" mode, the user interface becomes affected in regard to user-input to the individually displayed windows of applications on the VM, but not their frames.

This therefore appears to be related to another "bug" in that any older windowed seamless app that decides to go "full-screen" within the VM ends up completely corrupting the screen of the host - requiring some skill to either minimise/maximise or save/restart the VM in order to recover.

Specifically, I suspect it is down to whatever "full-screen-frame" that VirtualBox is using as a drawing surface when trying to place stuff as if the VM's virtual screen was the same size as the host's screen (visible background or not) - which I suppose is the key similarity between full-screen and seamless modes that might share a bug.

[Alex Tidmarsh]

May I suggest that the bug may be that any switch of desktops - and possibly also any attempt for a VM-app in the VM to go full-screen whilst the VM is seamless - may be losing the ability of a container-frame for the VM's display on the host to lose its ability to become the foreground window and so capture user input.

This assumption is because of the apparent ability to unlock the frozen VM's input by minimizing the VM and restoring it, or, alternatively, pausing, saving and restarting the VM.