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

[Anna Fischer]

> -----Ursprüngliche Nachricht-----
> Von: Frank Mehnert [mailto:frank.mehnert at oracle.com]
> Gesendet: Donnerstag, 25. Februar 2016 20:39
> An: vbox-dev at virtualbox.org
> Betreff: Re: [vbox-dev] Windows 10 guest additions video driver problem
> 
> 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/S
> > > up
> > > 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 will check again, but as far as I remember there haven't been any errors in the logs.

 
> > 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

The behavior I see is that the guest is changing to a lower resolution after host resume, but sometimes it hangs completely, e.g. does not take any mouse clicks anymore.

Anna