VirtualBox GUI unresponsive following long period of inactivity, yet VM still functioning

[Dekker]

OK, this is an odd problem.

First, my environment: Host: Windows 10 1703 x64 Guest: Ubuntu 17.04 with guest additions VirtualBox Version 5.1.28 r117968

VirtualBox and the VM work properly, with no operational problems. The issue happens when I return to the machine after leaving it unused overnight. In the morning, the VM window (I have it windowed, not full-screen) is white, with the usual "(Not responding)" appended in the title bar. Waiting 30 minutes or more does nothing.

The unusual part is that the VM IS still running! If I kill the VM and restart it, I can see internal logs and file activities right up to the moment I killed it. That leads me to believe it is VirtualBox that is losing connection with the guest.

Since I know of no way to connect again to the guest, I am forced to kill the VM and pray for minimal data loss.

Log files attached. The current log is for the VM that is still running (but not responding) but the VBox.log.1 is for the same problem encountered yesterday when I killed the VM. This happens pretty regularly, whenever I leave the machine operational for extended periods.

Two observations: VBoxHardening contains log spam for OpenGL32.DLL to the tune of 142k messages... This is similar to an old unresolved forum post (​https://forums.virtualbox.org/viewtopic.php?f=6&t=64118)

29e8.2ce8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ff839780000 'C:\WINDOWS\System32\OPENGL32.dll'
29e8.2ce8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ff839780000 'C:\WINDOWS\System32\OPENGL32.dll'
29e8.2ce8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ff839780000 'C:\WINDOWS\System32\OPENGL32.dll'
29e8.2ce8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ff839780000 'C:\WINDOWS\System32\OPENGL32.dll'

Second, my machine is connected by a KVM to another machine. Since I leave it to display my other physical machine overnight, the machine with the VM effectively has no display connected at all until the next morning. Nothing else seems to care about that fact, however since this is a display problem, I thought I'd mention that fact.

Whenever I switch the KVM back and forth, The following message appears in the VBox.Log. The 8:26 messages were my last machine switch of the day yesterday, and the 23:39 are (I believe) when I first switched back to the machine this morning. Switching back and forth now no longer generates log messages, as the VirtualBox GUI is frozen. I can still see network activity on the VM as well as file accesses (in ResourceMonitor), and I have no doubt the machine is functioning in the background still.

08:26:16.367569 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenResized: Screen 0 is formally resized to: 0x0 x 1600x1200
08:26:16.367705 GUI: UIMachineLogic: Host-screen geometry changed
08:26:16.367734 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenWorkAreaResized: Screen 0 work area is formally resized to: 0x0 x 1600x1200
08:26:16.367750 GUI: UIMachineLogic: Host-screen available-area changed
23:39:35.144963 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenResized: Screen 0 is formally resized to: 0x0 x 1920x1200
23:39:35.145139 GUI: UIMachineLogic: Host-screen geometry changed
23:39:35.145316 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenWorkAreaResized: Screen 0 work area is formally resized to: 0x0 x 1920x1200
23:39:35.145336 GUI: UIMachineLogic: Host-screen available-area changed

So, with all that information, is the problem indeed with VirtualBox?

[Dekker]

Log files from bug report

[Dekker]

The lack of any response means I must be the only one experiencing this, though a Google search finds others complaining of similar problems in unrelated forums... But I will press on anyway.

As an update, I have tried newer VBox builds and nothing seems to change. Randomly, after an extended absence such as overnight, I return to a WHITE or BLACK VBox window with "Not responding" in the title bar.

I had previously tried the bleeding edge 18.04, but that too showed problems. I have since re-installed Linux using the Ubuntu LTS 16.04 version, but the problem still occurs with the older version.

VBox.Log shows nothing between 08 and 24 that would indicate an interesting event. The screen size change is due to my use of a physical KVM to switch my keyboard/mouse/monitor between the HOST machine and a separate physical non VM machine. When the HOST machine loses the monitor, the screen size returns to its default (laptop) resolution, then returns when I switch back. The audio change is because I connected a bluetooth headset on the host (the audio device is not often used, and the problem exists even when no BT headset is connected)

08:24:03.319996 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenWorkAreaResized: Screen 0 work area is formally resized to: 0x0 x 1920x1200
08:24:03.320021 GUI: UIMachineLogic: Host-screen available-area changed
08:24:40.561669 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenResized: Screen 0 is formally resized to: 0x0 x 1600x1200
08:24:40.561749 GUI: UIMachineLogic: Host-screen geometry changed
08:24:40.562098 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenWorkAreaResized: Screen 0 work area is formally resized to: 0x0 x 1600x1200
08:24:40.562210 GUI: UIMachineLogic: Host-screen available-area changed
24:36:32.601548 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenResized: Screen 0 is formally resized to: 0x0 x 1920x1200
24:36:32.710945 GUI: UIMachineLogic: Host-screen geometry changed
24:36:32.978918 GUI: UIDesktopWidgetWatchdog::sltHandleHostScreenWorkAreaResized: Screen 0 work area is formally resized to: 0x0 x 1920x1200
24:36:33.008971 GUI: UIMachineLogic: Host-screen available-area changed
24:37:20.076790 Audio: Host audio device configuration has changed
24:37:20.085193 Audio: Host audio device configuration has changed
24:37:20.307529 Audio: Host audio device configuration has changed
24:37:21.929804 Audio: Host audio device configuration has changed
24:37:22.051373 Audio: Host audio device configuration has changed
24:37:22.181689 Audio: Host audio device configuration has changed
24:37:24.793480 Audio: Host audio device configuration has changed
24:37:25.370013 Audio: Host audio device configuration has changed
24:37:25.470149 Audio: Host audio device configuration has changed

The Hardening.log has the LdrLoadDll spam as before:

26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.c60: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.c60: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.c60: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
26ac.2190: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=00007ffacb210000 'C:\WINDOWS\System32\OPENGL32.dll'
21a8.1edc: supR3HardNtChildWaitFor[2]: Quitting: ExitCode=0xcfffffff (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 88791181 ms, the end);
269c.5fc: supR3HardNtChildWaitFor[1]: Quitting: ExitCode=0xcfffffff (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 88792159 ms, the end);

[Dekker]

Still no response, but the world has moved on.

VirtualBox 5.2.16 and 5.2.18 both are stable and have not exhibited this behaviour for months. I'm willing to say "it was fixed in the background" and close this ticket.

[janitor]

Thanks for the update.