Guest Windows Slowly Shrink and Jump Around on Resize

[jphands]

Hi, Fellow VBoxers!

I just upgraded to V 6.1.12 r139181 and I'm seeing some very odd behavior in guest windows.

Guest windows jump around randomly at irregular times, and now guest windows are slowly shrinking vertically unless maximized. Over a period of 15 - 20 minutes, a guest windows shrinks, vertically only, until it's just a minimal rectangle. Eventually, the guest aborts.
If I resize a guest window, it will jump elsewhere randomly - often to another screen, and then start shrinking.
If I move a guest window, say to the middle of the screen, it will jump to the right side of the screen after a few seconds, and then start shrinking.

This happens on both Windows and Linux guests, using both the VMSVGA and VBOXSVGA graphics controllers. It has only started since the update to this version...all was fine before that.

The host machine is an 8 physical core (16 virtual) AMD Ryzen 7 2700X PowerSpec G162 with an AMD Radeon RX580 GPU, with 48G RAM and 15Tb Storage so it can handle the VBox load.
The machine is running KDE Neon 5.19.4, which is KDE's own distro, based on Plasma 5.19.4 and the 5.14.2 Kernel. I have compositing switched on for full KDE effects.
I have 3 4k Monitors, although I don't thinks that's relevant.

I've attached a short screen recording - a zipped MP4 -to give you an idea.


Thanks,

Paul
Is anyone else seeing anything like this, or should I go straight to submitting a bug report?

[fth0]

Is anyone else seeing anything like this

Cool, I want that, too.

Just kidding! Please start a VM, reproduce the behavior, and shutdown the guest OS. Post a zipped VBox.log file and describe what you saw in that run.

[jphands]

OK - I started another Windows 10 Pro VM, and observed more closely.

The VM starts normally, and the initial window seems stable. The initial window size is too small, so I resize it to use more of the 4k monitor, and the shrinking starts immediately. Looking in the log file, it seems to be shrinking, vertically only, by 1 or 2 pixels every 2 - 3 seconds.. During this time, it's impossible to shut the guest down, because the constant redraws make it impossible to hit the Shut Down button quickly enough. Eventually, it shrinks to a vertical height of 103 pixels (at least for this Windows 10 Guest), and the shrinking stops. Any event that cause a resize starts the shrinking again, including the guest OS going to screen lock, which seems to auto-resize the guest window. Again, the shrinkage stops at 103 pixels in height.

The shrinking does not happen if the guest is set to full screen. The shrinking stops if the Guest OS goes into screen-saver mode, and resumes on wake-up.
A move and resize of the guest window causes it to snap back to the right side of the screen, and shrinking restarts.
A move without resizing snaps back to the screen right border, even if no shrinking occurs.

The experiment is very repeatable on both Windows and Linux guests.

The log file is attached, and contains a very large number of repeats of...

Code: Select all

00:04:30.078206 GUI: UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 2245x103 if necessary
00:04:30.182443 VMMDev: SetVideoModeHint: Got a video mode hint (2245x103x32)@(0x0),(1;0) at 0
00:04:30.182825 VMMDev: Guest Log: Got multi resize request 1 displays
00:04:30.182851 VMMDev: Guest Log: [0]: 0 0x39 0,0 2245x103 32
00:04:30.194294 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:04:30.205602 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=00007f9698000000 w=2245 h=103 bpp=32 cbLine=0x2314 flags=0x1 origin=0,0

The full log file is attached. Let me know if I should enter a bug report.

Paul

[fth0]

The full log file is attached.

No, it's not.

Please zip the log file before attaching it, and if you've already done so, split it so that the zip files are below 128 kB in size.

[jphands]

Rats....I didn't compress it.

Here it is, compressed to 41.2Kb

P

[fth0]

VirtualBox saves the last used window size in the VM configuration file (.vbox file), and uses it as the initial size hint during the next VM start:

00:00:01.895365 GUI: UIMachineViewNormal::resendSizeHint: Restoring guest size-hint for screen 0 to 1711x100

You can change the saved window size with the following command:

Code: Select all

VBoxManage setextradata "w10Pro" GUI/LastGuestSizeHint "1920,1080"

Note that common screen resolutions are usually multiples of 8 x 8, and most people use one of those. Note also that almost all resolutions in the VBox.log file have at least one odd number. Let me guess: Are you using a scale factor of 2?

[jphands]

According to the VBox Settings for the Display, the scale factor is 100%.

I'm not sure what that means, though.

I'm not particularly worried about the window's initial size....as long as it resizes correctly, and stays where i place it

[fth0]

scale factor is 100%

Then my guess was wrong. I suspected that with a scale factor of 200% and an odd resolution, VirtualBox may be trying to autocorrect the resolution.

Generally speaking, the window resolution can be changed via the VM window's menu to predefined resolutions, which are usually multiples of 8 by 8, and this is what most users do (besides using full screen). Then there is manually resizing with a mouse, which can lead to any resolution, even odd ones. Since this method isn't used much, I could imagine buggy behavior. So let's sort this out first:

Change the saved window size using VBoxManage setextradata "w10Pro" GUI/LastGuestSizeHint "1600,900" (deliberately smaller than a quarter of your screen resolution). Start the VM and see if the window still shrinks. If it doesn't, try with "1601,901", "1601,900", "1600,901" and "1601,100". Post the zipped VBox.log files.

I'm not particularly worried about the window's initial size

But that is the starting point for the VirtualBox behavior (after the initial resolution changes during boot), so maybe you should be.

[jphands]

Hi,

Sorry for the delay - was doing some work-related coding!

Just to be on the safe side, I logged out and restarted the X Server, as I've seen some oddities from Neon/Plasma with compositing on after a long time without a restart. I think something in there is leaking memory.

It made no difference anyway. Restarting the10Pro guest without setting the extradata displayed the same behaviour.

Then I set the extradata as described to 1920 x 1080, and it gave me a stable login window...so that idea is a good one.

However....

Any action that causes a resize - usually me manually resizing with the mouse, which I do a lot, leads to the shrinking behaviour.
If the guest window is not snapped to the screen's right edge, any resize causes the window to snap to the right screen edge before the shrinking starts.
The shrinking doesn't stop at the extradata preset vertical size. The w10Pro widow shrinks as before to a vertical height of 103 pixels. Interestingly, a KUbuntu 18.04 guest also stops shrinking at 103 vertical pixels.

My use case is a bit different in that I run a bunch of guest VMs on an internal network, so I can see how my app is responding on different platforms working together. I often put 5 or more Guest windows together by resizing them and effectively tiling them.

The log file for starting at 1920 x 1080 is attached here. Next I'll do the experiments with 1600x900 and so on.


Cheers,

Paul

[jphands]

Hmmm.....

Setting the initial size to 1600x900 has made things worse, at least at first.

The windows 10 guest window comes up at what seem the minimum height of 103 pixels, ignoring the size hint completely. Worse, when resized to try to see the login password box, the resize fails - the window grows, but the login screen remains at 103 pixels in the centre of the much bigger window - a letterbox view!
Entering the password blind worked eventually, and the guest window came up correctly....but then immediately started shrinking.

Log is attached.

[jphands]

OK - starting at 1601 x 901 was a little different.

The startup was the same - initial pre-boot window size looked right, but immediately shrank to 103 pixels and the right side of the screen for the login screen. Entering the password blind successfully logged in, but the desktop stayed as a thin letterbox at 103 pixels. Resizing caused the desktop to show correctly, but shrinking began immediately.

Log is attached.

[jphands]

Just did 1601x900. It was identical to 1601x901.

Log attached.

[jphands]

1600x901 behaved identically to the previous experiment.

1601x100 seemed to ignore the size hint, and the login went as before, but correctly drew the desktop. As before a minor resize caused shrinking to 103 pixels.

Both logs are attached..

[jphands]

Just for info....I upgraded VBox to the new version... Version 6.1.14 r140239 (Qt5.14.2) and updated the Extension Pack and Guest additions to the latest versions. The shrinking behaviour is still there.
Changing the graphics controller to VBoxVGA made no difference.
Changing the graphics controller to VMSVGA stopped the shrinking, but also stopped the guest resizing to fit the window, as if the guest extensions had not been installed. Trying to reinstall the guest extensions fails because some hardware isn't found.
Reverting to VBoxSVGA restored everything to as-before, including the shrinking.
3D Acceleration makes no difference whether on or off.

[Dhry]

Did you ever solve this issue? I'm seeing the same thing - Windows on latest 7.0.2 VirtualBox, guest is Windows 2012 R2. Window just shrinks pixel line by pixel line, about three or four lines per second. I have a fairly fast machine, 64Gb ram, 16 core 3950x CPU, RTX 3080 card (if it matters).
If I turn off the auto resizing the shrinking stops.

Dhry