virtualbox.org

Running Ubuntu 8.1, with all current updates, including kernel 2.6.27-14-generic My VirtualBox is updated to the latest 3.02 The most often run guest machine is Windows XP SP3., but I've noticed the problem inside of Windows7 RC machines as well.

The display inside of VM's begins flickering after some hours of use, then degrades as time goes on. Given enough time, the display just goes black, and the controls within the VM window blank out. Clicking where the buttons belong has no effect, so they haven't just turned "invisible".

I've double checked that the Guest Additions are updated to version 3.02, double checked that video acceleration is disabled, and I'm only using 64MB of memory for video. I am not using the optional directx support within the guest additions.

I attempted to repair the problem by re-installing VirtualBox, with no result. I attempted to re-install the guest additions, and ditto.

I would consider blaming the problem on VBox v 3.02, but I've been running it for weeks. Only in the past 4 or 5 days has this problem appeared, so going back to version 2.x seems unlikely to fix the problem.

The machine is AMD 3400+ on an Asus K8N mainboard, 3 gig of memory. Video is onboard Nvidia nForce3 250

The two possibilities that come to mind, are that A: I've updated something that I probably didn't need to or B: the onboard video chip is being overstressed. The problem with B: is, I see no corruption of video on the host machine - only the guest seems to be affected.

I can't even say what I've updated within the last few weeks. I've fallen into the habit of just installing whatever the update reminder offers. I know - bad idea.

Has anyone had similar issues?

To try and track this down, I would (after an event ) look at the log file for the guest and see if there are any indications of what the problem may be.
Memory leak is the first thing that comes to my mind and can be caused by a lot of different things or programs. I would not discount VBox as having the problem at this point although it does seem unusual due to the fact there are so many using the product and I don't hear this type of problem very often.

Fired up the problematic VM today (yesterday, actually) and it ran for hours. Rock solid, without any sort of problem. This evening, I decided to start a download that I've been trying to finish. Within about 3 hours, little things started happening to the video. As the evening progressed, I saw more and more video errors.

I'm pretty sure that the problem is related to WinHTTrack from these fine folk: http://www.httrack.com/

I'm not sure which log I should be looking at. There is a VBox.log, Vbox.log.2, Vbox.log.2 and Vbox.log.4.

This is the tail end of VBox.log:

13:22:32.724 VBVA: Enabled.
13:25:51.121 Guest Log: VBOXNP: DLL loaded.
13:25:58.578 Guest Log: VBOXNP: DLL loaded.
13:25:58.898 SharedFolders host service: request to map folder Desktop
13:25:58.898 SharedFolders host service: map operation result VINF_SUCCESS.
13:25:58.898 Mapped to handle 0.
13:26:08.934 SharedFolders host service: request to unmap folder handle 0
13:26:08.934 SharedFolders host service: unmap operation result VINF_SUCCESS.
13:26:48.101 SharedFolders host service: request to map folder Desktop
13:26:48.101 SharedFolders host service: map operation result VINF_SUCCESS.
13:26:48.101 Mapped to handle 0.
13:26:58.153 SharedFolders host service: request to unmap folder handle 0
13:26:58.153 SharedFolders host service: unmap operation result VINF_SUCCESS.
14:02:37.833 VMMDev::SetVideoModeHint: got a video mode hint (1024x649x0) at 0
14:02:37.985 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=649 bpp=32 cbLine=0x1000
14:02:37.985 VBVA: Disabled.
14:02:38.013 VBVA: Enabled.
14:03:13.676 VMMDev::SetVideoModeHint: got a video mode hint (1024x768x0) at 0
14:03:13.913 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=768 bpp=32 cbLine=0x1000
14:03:13.913 VBVA: Disabled.
14:03:13.919 VBVA: Enabled.
14:03:23.252 VMMDev::SetVideoModeHint: got a video mode hint (1024x649x0) at 0
14:03:23.392 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=649 bpp=32 cbLine=0x1000
14:03:23.392 VBVA: Disabled.
14:03:23.408 VBVA: Enabled.
14:03:46.060 VMMDev::SetVideoModeHint: got a video mode hint (1024x768x0) at 0
14:03:46.295 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=768 bpp=32 cbLine=0x1000
14:03:46.295 VBVA: Disabled.
14:03:46.302 VBVA: Enabled.
14:03:52.751 VMMDev::SetVideoModeHint: got a video mode hint (1024x649x0) at 0
14:03:52.802 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=649 bpp=32 cbLine=0x1000
14:03:52.802 VBVA: Disabled.
14:03:52.819 VBVA: Enabled.
14:05:47.010 VMMDev::SetVideoModeHint: got a video mode hint (1024x768x0) at 0
14:05:47.144 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=768 bpp=32 cbLine=0x1000
14:05:47.145 VBVA: Disabled.
14:05:47.150 VBVA: Enabled.
14:22:55.589 SharedFolders host service: request to map folder Desktop
14:22:55.589 SharedFolders host service: map operation result VINF_SUCCESS.
14:22:55.589 Mapped to handle 0.
14:23:05.657 SharedFolders host service: request to unmap folder handle 0
14:23:05.657 SharedFolders host service: unmap operation result VINF_SUCCESS.
14:45:47.781 Guest Log: VBOXNP: DLL unloaded.
15:06:11.241 VMMDev::SetVideoModeHint: got a video mode hint (1024x649x0) at 0
15:06:11.802 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=649 bpp=32 cbLine=0x1000
15:06:11.817 VBVA: Disabled.
15:06:11.888 VBVA: Enabled.
15:19:40.565 Changing the VM state from 'RUNNING' to 'SUSPENDED'.
15:19:49.689 Changing the VM state from 'SUSPENDED' to 'RUNNING'.

I can change state from running to suspended and back again, with no change in the black video display. (From right-click menu in main VirtualBox window)

15:19:40.565 Changing the VM state from 'RUNNING' to 'SUSPENDED'.
15:19:49.689 Changing the VM state from 'SUSPENDED' to 'RUNNING'.
15:22:49.072 Changing the VM state from 'RUNNING' to 'SUSPENDED'.
15:22:54.171 Changing the VM state from 'SUSPENDED' to 'RUNNING'.

I can also rtCTRL-F the screen back and forth:

15:25:23.318 VMMDev::SetVideoModeHint: got a video mode hint (1024x768x0) at 0
15:25:23.516 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=768 bpp=32 cbLine=0x1000
15:25:23.516 VBVA: Disabled.
15:25:23.531 VBVA: Enabled.
15:25:26.502 VMMDev::SetVideoModeHint: got a video mode hint (1024x649x0) at 0
15:25:26.649 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f00316b6000 w=1024 h=649 bpp=32 cbLine=0x1000
15:25:26.650 VBVA: Disabled.
15:25:26.655 VBVA: Enabled.


Further, checking my eth3 with Wireshark shows me that the VM is still communicating with the outside world. Apparently, nothing inside the VM has crashed.

So, I'm left wondering how on earth a networking program can interfere with video? Makes no sense to me!!

Do you need any copies of logfiles or anything? I can browse them all night, and not make a lot of sense of them.

With all menus in the VM window disabled, there is no way to gracefully shutdown the VM. It would be a nice feature if some graceful shutdown option were available in the main Sun VirtualBox window - but I don't guess a lot of people need that very often. Alternatively, if I had "remote logon" enabled within the VM, I could MAYBE use another machine to shut it down. *scratching head*


Thanks!

WHOA!! Sometimes, my brain works slowly, but another idea just occured to me.

Background, I positively HATE Windows Explorer. (almost as much as I ever hated Internet Explorer prior to v.7) I insist on using some file manager that resembles the old DOS Shell, or Norton Commander. For years, I've been using PowerDesk - now owned by AvanQuest. http://www.avanquest.com/USA/software/p ... ro-7-96228

I installed into a VM running Windows7 RC, and things got ugly. Using PowerDesk as a system integrated replacement for Windows Explorer is impossible, all sorts of things stop working properly. I blamed that on Win7 incompatibility, 100%.

However - after a little thought, it seems to me that HTTracks works alright, until I start PowerDesk up. The next time I start this VM, I will NOT use PowerDesk at all.

I will now kill the VM, start it up again, and allow HTTracks to run through the night. If it freezes again, I can probably rule out PowerDesk.

I'm ready to say that my problem was due to some interaction between HTTracks and PowerDesk. HTTracks has been running for 11 hours 44 minutes now. I can play multimedia, browse the file system using Windows Explorer, browse the internet, and use various utilities in the VM, without any hint of video corruption.

Odd that this sort of an incompatiblity manifests as a video problem. I hope to finish this site mirror soon, then I'll play around with the two applications to see how I can really screw things up.