Visual Studio 2010 provokes desktop re-sizing (new in 4.1.6)

[Ken Hagan]

I've run Visual Studio 2010 quite happily in my XP guest for some time, having disabled/not-installed all the DirectX acceleration to force VS *not* to attempt fancy graphics. (I believe this is the accepted workaround for a known problem.)

However, as of version 4.1.6, starting Visual Studio causes a never-ending sequence of desktop resizing events, several per second (apparently CPU-limited) between "normal" and "VGA res". The system is then basically unusable and the only escape is sending Ctrl-Alt-Del followed by "Logout".

Despite the unusability, it isn't a great problem since I'm happy to revert to the previous version, but is anyone else getting this? Any experiments worth trying before I downgrade?

(The log appears unhelpful, merely recording the events:

00:12:26.393 Guest Log: VBoxDisp[0]: VBVA enabled
00:12:26.393 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=1152 h=864 bpp=32 cbLine=0x1200, flags=0x1
00:12:26.413 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=1152 h=864 bpp=32 cbLine=0x1200, flags=0x1
00:12:26.883 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=640 h=480 bpp=16 cbLine=0x500, flags=0x1
00:12:26.883 Guest Log: VBoxDisp[0]: VBVA enabled
00:12:26.883 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=640 h=480 bpp=16 cbLine=0x500, flags=0x1
00:12:26.883 Display::handleDisplayResize(): Warning: resize postponed.
00:12:26.904 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=640 h=480 bpp=16 cbLine=0x500, flags=0x1
00:12:27.042 Guest Log: VBoxDisp[0]: VBVA enabled
00:12:27.042 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=640 h=480 bpp=32 cbLine=0xA00, flags=0x1
00:12:27.062 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=640 h=480 bpp=32 cbLine=0xA00, flags=0x1
00:12:27.223 Guest Log: VBoxDisp[0]: VBVA enabled
00:12:27.223 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=1152 h=864 bpp=32 cbLine=0x1200, flags=0x1
00:12:27.243 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=06000000 w=1152 h=864 bpp=32 cbLine=0x1200, flags=0x1

..continued ad nauseam.)

[Ken Hagan]

It doesn't happen if I start the VM headless and use remote desktop. I'm not surprised by this, but I mention it as another workaround if there's anyone else out there troubled by this.

[Ken Hagan]

Now that I have more time, I have returned to try some more things and I find that the problem has gone away. The only two changes I'm aware of are (i) switching to the para-virtualised network adapter, and (ii) installing an update relating to certificate validation. Neither would appear to be remotely relevant. Perhaps running under Remote Desktop caused a few warts to be flushed away.

Anyway, as far as I'm concerned, there is no longer a problem.

[Ken Hagan]

(Another update for the benefit of anyone finding this thread with a search engine.)

I installed 4.1.8 yesterday and found that the problem recurs. Remote Desktop is still a viable workaround, but the problem no longer "goes away" when I go back to direct console access. That's the bad news.

The good news is that I discovered that I no longer need to remove Direct3D acceleration from a VM before installing/running Visual Studio 2010, and enabling it appears to circumvent this desktop re-sizing problem. I couldn't say whether this is the result of patches to Visual Studio or to VirtualBox, but it is a welcome discovery.