Virtualbox often crashes when Win7 host awakes from screensaver

[Jyrgen]

System and setup

---

Dell Latitude E6430 CPU: Core i7-3720QM RAM: 8 GB DDR3 1600 MHz SSD: 256 GB Samsung 830 Video: Intel HD 4000 and Nvidia NVS 5200M Host OS: Windows 7 Enterprise x64 SP1 Guest OS: Linux Mint x86_64 3.2.0-32-generic (KDE desktop) Monitors: Laptop display, main dipslay at 2560x1440, third display at 1024x1280 (tilted 90 degrees)

• Guest OS uses two displays (main and third display)
• Guest OS is running (smoothly) inside a truecrypt disk

Virtualbox: 4.2.4 + extension pack + guest OS tools installed Crash description

---

When Windows is awaken from screensaver Virtualbox often crashes. It always crashes when I detach laptop from docking station - external monitors are detached from the system. Of course, these crashes only happen when my Guest OS is running.

[Jyrgen]

VBox Log file

[daveloyall]

Same issue.

Host is Microsoft Windows [Version 6.1.7601] (Win 7 Enterprise SP1).

Guest is 64bit Debian Linux.

I have three displays on the host and the guest is configured to use two of them in fullscreen mode (not RDP).

I think that deactivation of screen blanking on the guest could have something to do with it. I'm not running fancy screen savers there, it's whatever default screen blanking that comes with xorg + slim + awesome (window manager).

In the meantime, I have unchecked the "3D support (experimental)" box. I will post another VBox.log if the crash occurs again, or post back in a week if unchecking the box did the trick.

Cheers,
--Dave

p.s. Oracle required me to provide my mailing address and job title before I could post this bug report to an open source project. This makes me forkin' mad. (Get it, innotek?)

[daveloyall]

Happened again, but this time the host was NOT in a screensaver, it was active, but screenblanking had been activated in the guest. I clicked into the guest, then POOF, no more guest.

Other times, screen blanking has been active in the guest, then I click in, and it's fine.

During normal runtime, I have two Windows on the host, one for the left Guest monitor, one for the right Guest monitor. During Guest screenblanking, one of these disappears from the host. (Left, right, 1, 0, who knows? None of the identifiers match from guest to host--it doesn't help that there are three physical monitors: 3, 1, 2, in that order. Further, I think that they change dynamically when xrandr events happen, because I can't get directly adjacent x screen buffers unless I use physical monitors 1 and 2. Note: I'm not complaining, I love vbox's multiple monitor support; I use it all day!)

Other details: unlike the original poster, I'm not using encryption, and none of my displays are rotated. As you can infer from the vbox.log.2.1, I'm not using the experimental 3D option anymore.

My host is 64bit.

I don't know if the last timestamp in the log is the time of the crash, or hours before. Maybe I'll think to inspect the log while it is running, sometime.

I'd be happy to provide a process image dump, or whatever will help you, just describe what you need. (I'm a Java developer, not a C developer.)

Cheers, --Dave

[daveloyall]

I can reproduce this.

In an xterm, issue the command:

xset s 1 2

Your screen will blank after 1 second of activity and "cycle" (whatever that means) every two seconds.

Now, move your mouse back and forth between the host and the guest, about once every three seconds. (The intended result is that you will activate and deactivate your screen blanking several times, with enough time for the "cycle" event to happen.)

On my system, this will reliably crash VirtualBox.exe after less than ten tries. EDIT: Okay, twenty tries. :)

I will use xset to DISABLE screen blanking and report back in a week if that puts and end to the crashes.

Cheers, --Dave

[daveloyall]

No crashes for a week.

Here is my workaround:

I created a file /etc/X11/Xsession.d/97dloyallxset with this content:

    xset s 0 0
    xset dpms 0 0 0

On my system, the file is executed (sourced, actually) during Xorg startup. You could manually run those commands in an xterm instead.

Hope this is helpful, cheers,

--Dave

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.