OpenGL has performance and drawing issues after 6.0.6 update.

[boxer01]

After update to the aforementioned version my Windows 10 1809 host and guest got some problems. First of all the startup time is now double or triple as much as before. One can see the system starting as one would moved back from SSD to plain old HDD. Even if one see something there is a slow reaction on the keyboard and mouse events. So it takes more time from the start of the VM till the moment where you can do something with it.

The other one: as soon as host try to dime the display or turn it off, the content of the VM turns black. The programs work fine and you can hear the sound, but you can’t see anything, just black square. The mouse cursor changes itself in case you move it over some places (like border of the program’s window or the link in the browser). I could blindly shutdown the VM through keyboard commands directly in VM. There are some topics (​92756,​92757) in the forum describing the same behavior. Some other tickets (#18564, #18582) are probably depends on this issue.

I tested with 5.2.28, current 5.2.29 and 6.0.7 with the same result. Going back to the 6.0.4, 5.2.26 or 5.2.22 solves this. I saw some changes in the OpenGL using code in the last to weeks, maybe this causing this behavior? I put my logs here, I could see some OpenGL warnings and errors here just 12 minutes after the VM start.

Funny enough this not happens on my older Windows 7 guest — Windows 8.1 host system. The Windows 10 systems are all Core i5 3xxx with build-in graphics, also not the youngest ones, but not as old as Windows 8.1 system.

[boxer01]

Window 10 system logs, Part 1

[boxer01]

Windows 10 system logs, Part 2

[Neofisher]

I have noticed a similar issue. Since upgrading to 6.0.6. Windows 10 (1809) only shows a blackscreen if both Guest Additions is installed and 3D acceleration is enabled. This applies for both pre-existing VMs created prior to the update, which did not suffer this issue; and fresh VMs installed from Windows 10 iso.

Tested on CentOS 7 host operating system.

[gone]

I think I was seeing this problem too. Linux Kubuntu 18.10 host, Windows 10 1809 guest. Dual head host and guest.

After a time both monitors of the guest would go completely black, but somebody's mouse cursor could be moved (and be seen moving) on the guest monitors.

The only recovery seemed to be file >> close on the VM window.

I went into windows settings and set "power save" to "never", and now the problem does not seem to occur. But I have since downgraded (for reasons unrelated to this particular problem) to VirtualBox 6.0.4, so I can't be sure.

FWIW

[boxer01]

Just as information: on current 5.2.29 it takes 75 seconds from the start to the desktop appearance. And I need another 20 seconds to get reaction from the windows explorer window I open as a first action in the VM. On the current 6.0.7 it is 70 seconds plus another 10 seconds. On the older version (5.2.22, 5.2.26 or 6.0.4) with the same host, guest and VM I need just 35 seconds to start the VM and everything works and reacts just immediately. So you can really see the slowness here even without the chronograph.

[Quppa]

This is happening to me, too - in my case the guest is a fresh install of Windows 10 19H1 (updated to 18362.86) and the host is a fresh install of Fedora 30. Not much else to add - there doesn't seem to be anything useful in the Windows Event Viewer. For now I'm working around it by having the (virtual) screen never turn off, as @gone indicated.

[boxer01]

Logs from 5.22, 5.2.29 and 6.0.7 to compare because of some OpenGL warnings, issues and errors in late versions. See the logs.

[boxer01]

I put my logs from all 3 versions here. If you compare the logs from 5.2.22 with the one from 5.2.20 or from 6.0.7 you see, that all operation takes more time or start later than in 5.2.22. The other big difference: there are some OpenGL warning about crPixelCopy3D in all of them, but only newer ones have some warnings about DxgkDdiQueryCurrentFenceNew and uncompleted fences. Probably this is the cause of those troubles? There are more messages from Dx, OpenGL and VMMDev in newer versions then in old ones.

[gmu]

Hi, i'm experiencing a similar bug : black screen in windows guest after that the display has been turned automaticly off ! And the only recovery seemed to be file >> close on the VM Guest

My Host is Linux openSUSE Tumbleweed, kernel 5.0.11-1-default,3 display GLX version: 1.4, openGL 4.6.0 NVIDIA 418.74, guest has accelerated 3D&2D enabled and also 3 display, it's a M$windows 10pro64bit, GuestAdditions installed of course. VirtualBox with the problem 6.0.6 but with prior version i don't notice this problem. After changing the windows Power Options to ON battery power, turn off after : NEVER & When plugged in, turn off after : NEVER, These changes should circumvent the bug, i will be trying. Because for the moment i was downgrading to prior version 6.0.4.

[boxer01]

Just tested with the current 6.0.8 / 6.0.9 (130520, 130970) and 5.2.30 / 5.2.31 (130521, 130893) and there are no changes. I see fewer warnings in the log, but the main problem is still the same, after the display is turned off because of the energy saving, the whole guest screen is black. I put my current logs here so somebody could get more information.

[boxer01]

Logs from 5.2.31-130748 and 6.0.9-130868

[boxer01]

Logs from 5.2.31-130893 and 6.0.9-130970

[frg]

I think this started after 6.0.5 129220 which was still ok. I didn't notice it first but now updating the vm with wsus offiline ​http://www.wsusoffline.net/ results in a blank screen every time because it installs its own power scheme. Happens for me in 7 8.1 10 and the server variants. The fun thing is you still can use Ctrl-Alt-Del and the entry screen will be shown.

[dkardell]

Still Black Screen after Windows10 goes to sleep. Unable to "wake up" from black screen.

VirtualBox Graphical User Interface Version 6.0.8 r130520 (Qt5.6.3)

[sunlover]

The black screen problem should be fixed in VirtualBox 6.0.x r131597. See https://www.virtualbox.org/wiki/Testbuilds

[Socratis]

@sunlover

I tested it with a Win10-64 client and VirtualBox 6.0.9 r131597, on an OSX 10.11.6 host. The VM went to sleep 3 times and it woke up successfully 3 times.

I'd say it's fixed on my small scale test...

[boxer01]

Replying to sunlover: I just tested it on my Windows 10 1809 host and guest combo. Version 6.0.9-131597 works fine now, but this issue remains in the version 5.2.31-131558. Is it possible to merge the changes in the 5.2.x branch? My Windows 8 host / Windows 7 guest combo still works fine with each of these versions.

[boxer01]

As of 6.0.10 and 5.2.32 this issue is resolved on all my systems and this ticket could be closed.

[VBoxer1]

Sorry, I can't confirm the solution. After update to 5.2.32 the black screen remains. My host is Windows 7, the guest is Windows 10.

[Socratis]

@VBoxer1

How about 6.0.10, did you try that? Because I don't see any mentions that the fix was backported to 5.2.x...

[VBoxer1]

I avoided updating to version 6 because after a test I find the 6x user interface has got awkward. In comment 13 I read that the problem was fixed in 6.0.10 and 5.2.32. OTOH I don't see it is fixed in 6.0.10's changelog. Thus I'm reporting back that it might not really be fixed until now.

[boxer01]

Replying to VBoxer1:

Just tested once again with a fresh 5.2.33-132430 and 6.0.11-132407. I have no such problems on any of my systems (Windows 8 x64 host and Windows 7 x86 guest; Windows 10 1809 x64 guest and host). But: I’m using the fresh 6.0.11 guest additions only. Probably, this is important detail, if this bug was in the code of the additions and patch wasn’t back-ported. Could you simply download the ISO file of 6.0.10 or 6.0.11 and install that version from the mounted ISO?

[Socratis]

Replying to VBoxer1:

I avoided updating to version 6 ... I also need 32 bit support to run older VMs.

32-bit host support? Because that's what's been removed from the 6.x.x series, the support for 32-bit hosts. Not guests.

Replying to boxer01:

But: I’m using the fresh 6.0.11 guest additions only

boxer01, you're using the 5.2.3x main program with the 6.0.11 GAs? And it works? Impressive! :)

[boxer01]

Replying to socratis:

boxer01, you're using the 5.2.3x main program with the 6.0.11 GAs? And it works? Impressive! :)

Yes, I was also impressed back then. I think it was back in January 2019, I just tested both versions (5.2.x and 6.0.x) and just forgot to downgrade the GA to the 5.2.x one. As I saw that I run with a GA for a different version, the VM was already worked for hours without any issues. So since then I only downgrade to the earlier version if there are some issues and I would like to explicitly exclude the wrong version of GA as a source.

If this is still the source of the troubles for the ones who use the 5.2.x versions, would the developers mind porting the patch from the 6.0.x branch to the 5.2.x one?