Fullscreen guest aborted by HP laptop undock

[Simon Coleman]

I can reliably crash either of my guests by undocking my laptop when running a vbox guest in a fullscreen on an external monitor.

I have a patched windows 10 laptop host running V 5.10 2x guests, win7-64 & win10, both patched & running GA.

When docked I have 2x external HDMI monitors & a laptop display available. The laptop display resolution is identical to one of the monitors (and the other is the same resolution in portrait format).

The guests are configured to use 2x monitors & I can direct fullscreen output to any pair without difficulty.

Both guest types will be aborted only if an Undock occurs when they are fullscreen & are using one of the external monitors.

The following cases work successfully:

• Docked, 2nd monitor -> guest running Fullscreen mode -> hdmi disconnected -> Fullscreen guest moved to another monitor

• Docked, 2nd monitor -> guest Non-fullscreen (Windowed?) -> Undocked -> guest windows moved to another monitor

• Undocked, laptop displayport monitor -> Fullscreen guest on -> disconnect hdmi cable -> fullscreen window moves to laptop screen

This case does *not* work

• Docked, 2nd monitor -> guest running fullscreen -> Undock -> guest aborted

When undocking the laptop (separate switch to disconnect the base station, this also cuts ethernet, power & usb devices, although I do not knowingly have any USB passed through.

The win64 guest is a p2v machine (with some cruddy HP device drivers I can't uninstall), but the win10 machine is a clean ISO install done on this laptop. Both behave identically when it comes to aborting on undock.

It does not seem to make a difference as to whether the disconnected monitor is set as a primary in the guest or which virtual monitor is assigned.

The error is always a memory read error & does not appear to show in the log.

Any assistance appreciated.

[Simon Coleman]

win10 guest log

[Simon Coleman]

This looks very very similar to ticket #16195 where the OP reports a guest crash every time he disables the fullscreen guest with xrandr.

[C0RD]

My Setup: Laptop (Thinkpad T540p) with two external DisplayPort-attached Monitors.

Virtualbox with a Linux (Debian unstable) Guest runs Fullscreen on one of those.

When I switch the Monitor off and on again, it crashes reproducible when the display registers again.

As I'm forced to run my Windows Host in German Virtualbox produces this message:

"Die Anweisung in 0x75734756 [seems to change every time] verweist auf Speicher 0x00000008 [seems to be the same everytime]. Der Vorgang read konnte nicht im Speicher durchgeführt werden.

Looks like it didn't happen in Windowed mode.

[C0RD]

Hi,

After a night with switched off monitor, the Guest has crashed again when i switched the monitor back on.

So: Bug still present in Virtualbox 5.1.14

Cord

[Frank Mehnert]

C0RD, thanks for the information! simonc, please reopen if still relevant with 5.1.18.

[Simon Coleman]

hi, Good news - it appears undock is fixed for multiple monitors running fullscreen & undocking.

Unfortunately I think there are still some problems related to multimonitor handling.

Until last week I have been running 5.1.18 & guests with only a single monitor attached. No problems with monitor switches either for undock, lock or sleep with a guest running fullscreen on windowed on any display.

Forgetting this problem I added a 2nd display to the guest a couple of days ago.

The guest had 2x fullscreen windows on 2x non-primary monitors, although one of those windows was minimised.

Host locked & on unlock I discovered a guest crash & machine aborted. I upgraded to 5.1.20 yesterday, setup the same scenario today & received the same crash.

It appears to be a similar memory read error I was getting in 5.1.14.

I am just setting a similar scenario to test 2x guest windows fullscreen & what happens when the host locks.

simon

[Simon Coleman]

Yes, problem occurs when 2x guest windows are running fullscreen on secondary monitors & the host locks. On unlock the guest is aborted with a null pointer exception.

simon

[Simon Coleman]

And also now fails when undocking my fullscreen single-monitor VM again. [perhaps I was just being really careful about pausing vm & coming out of fullscreen before undocking - it may never have been fully fixed in this scenario]

[Simon Coleman]

Apologies, I did not manage to reset status when updating the comment above. But I now have a much more precise test case.

The crash relates to screen resizing which takes place when external monitors are detached, but only if the guest is running (not paused)

Vbox 5.1.22, fully patched win10 host & guests.

3 displays: inbuilt, monitor 1 & monitor 2. All monitors are identical pixel count, but monitor 1 is *portrait* format, (the others are landscape). One screen has a different resolution of the same area [1080x1920 as opposed to 1920x1080]

After setting 1 external monitor to run different dimensions to the others (as above), there are no problems if I pause the fullscreen VM before undocking. Undocking when the fullscreen vm is running on 2 external monitors works perfectly: both displays are moved to the inbuilt display. The VM can be unpaused & has the correct size/orientation for the inbuilt display. Redocking moves the displays back.

Setting all 3 monitors to identical resolutions allows the undock to work correctly with the running VM. Undocking the fullscreen vm running on the 2 external monitors works perfectly: both displays are moved to the inbuilt display. Redocking moves them back.

If I set 1 external monitor to a different resolution (its normal configuration) I can run the VM on the external displays & with the VM left running I can successfully use the tools menu to move the VM displays between any of the monitors, with resolution change apparently correctly taking place in the guest.

Normal running sees the VM running fullscreen on 2x external monitors, one of which is a different resolution to the inbuilt display. Unlike the case where the VM was paused, if the VM is left running & the undock occurs then the result is a crashed VM.

Presumably this is since everything happens together: the display is removed (outside vbox's control), it has to resize the guest display & notify the guest to resize desktop to fit as well. I have noticed a number of other (related) defect reports:

#16195 - same behaviour with a linux host (which I commented on/xref to here)

#16059 - similar behaviour on archlinux

#15863 - archlinux host problems relating to guest resize when monitors are moving around

let me know if any specific logs/tests will help (or if there is a proposed fix that needs testing first)

[Simon Coleman]

Appears fixed in 5.1.24

[Frank Mehnert]

Thanks for the information!