[vbox-dev] Windows 10 guest additions video driver problem

[Frank Mehnert]

Anna,

On Thursday 25 February 2016 19:26:08 Anna Fischer wrote:
> > Betreff: Re: [vbox-dev] Windows 10 guest additions video driver problem
> > 
> > Hi,
> > 
> > On Monday 04 January 2016 17:21:33 Anna Fischer wrote:
> > > > Betreff: Re: [vbox-dev] Windows 10 guest additions video driver
> > > > 
> > > > problem On Tuesday 29 December 2015 12:54:01 Anna Fischer wrote:
> > > > > I run Virtualbox 5.0.10 on Gentoo Linux. I run different guest
> > > > > operating systems, one of them Windows 10 64-bit. All my guests
> > > > > have
> > > > > 5.0.10 guest additions installed. All guests work fine except the
> > > > > Windows 10 guest: when I suspend the system (e.g. the host OS goes
> > > > > into hibernation / suspend to RAM mode) while the VM is running,
> > > > > and then resume the system, it seems as if the guest graphics
> > > > > driver crashes. Initially when the VM comes back on the screen
> > > > > after resume, it seems as if the resolution is switched to a lower
> > > > > resolution, and then I get a message in the guest saying video
> > > > > driver crashed. Has anyone else ever seen this? I only seem to
> > > > > have the problem with Windows 10 as guest. All other guests still
> > > > > work after resume, and their
> > > > 
> > > > resolution does not change.
> > > > 
> > > > do you see the same problem if you suspend + resume the VM? I'm
> > > > asking because basically this is the same what happens when you
> > > > hibernate or suspend your host: All VMs are suspended before the
> > > > host suspends and all VMs which were suspended before are resumed
> > 
> > after the host resumed.
> > 
> > > No, I don't see the same behavior, and I was expecting that it is a
> > > different mechanism. Does VBOX actually detect that the host is trying
> > > to hibernate, and then it will suspend all the VMs automatically? Is
> > > that really how it works?
> > 
> > yes, at least if dbus works as expected, see here:
> > 
> > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Main/src-> > server/linux/HostPowerLinux.cpp#L134
> > 
> > and here:
> > 
> > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Main/src-> > server/HostPower.cpp#L74
> > 
> > and later we will arrive Main/src/client/ConsoleImpl.cpp line 6195.
> > 
> > The VBox.log file of running VMs should indicate if they are suspended/
> > resumed on host suspend/resume.
> 
> To me the code looks as if the VM is actually paused, not suspended (e.g.
> saved). Is that so?

Yes. VBox terminology:

suspend(pause)/resume:
  stop/continue the execution of the VM. The VM process remains.

savestate:
  save the VM state to disk and terminate the VM process

restorestate:
  start a new VM process and load the state from disk

> It does not make sense to actually really suspend a VM (e.g. save state),
> because for Windows 10 with 4-8 GB of RAM, this will take up to 30 seconds!

Of course. Therefore we only pause/resume the VM in that case.

> During that time, my Linux is already suspended. It does not wait for VBOX
> to store any VMs.
> > > To me it looks like the host is just putting everything that currently
> > > runs to sleep, and then stores the RAM state on the SWAP partition.
> > 
> > Only if the dbus mechanism doesn't work. There is a different mechanism
> > which works in host R0, see here:
> > 
> > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/HostDrivers/Sup
> > port/linux/SUPDrv-linux.c#L604
> > 
> > The corresponding callback is registered here:
> > 
> > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/VMM/VMMR0/
> > HMR0.cpp#L707
> > 
> > This second mechanism is used to disable VT-x/AMD-V during host suspend
> > because many BIOSes are broken and don't handle this case properly.
> > 
> > > When I simply save and resume VMs (I do that all the time, btw.) it
> > > works perfectly fine.
> > 
> > In that case please check the VBox.log file is the VM is really suspended/
> > resumed during host suspend/resume. The VM should properly work after
> > host suspend/resume even if the first (dbus) mechanism doesn't work but it
> > makes sense to check if repairing it (if it doesn't work) makes a
> > difference.
> > 
> > dbus is loaded on demand to VBoxSVC, if libdbus-1.so.3 is not there then
> > VBoxSVC.log will contain the line
> > 
> >   HostPowerServiceLinux: DBus library not found.  Service not available.
> 
> I use DBUS for many of my own services, so it does run properly.

That does not answer the question if VBox really finds the library :-)
Any suspicious lines in VBoxSVC.log? Using strace to check which
library is loaded by VBoxSVC makes sense as well. Just start VBoxSVC
as separate process like

  strace -s128 -o log -f VBoxSVC

then start the VM in a separate terminal and later check if libdbus-1.so.3
is really found.

> I'm still wondering if this is a Guest Additions bug in Windows 10...
> I'm also wondering if this ticket https://www.virtualbox.org/ticket/14409 is
> the same as what I see, just under Linux. When I pause the VM manually, I
> do not see the same effect. So there must be something is going on when
> suspending the host.

I doubt that. Ticket 14409 was about a mis-behavior of the Windows guest
graphics driver. The relevant changeset is here:

  https://www.virtualbox.org/changeset/59518/vbox

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher