non-VT-X/AMD-V mode broken in 3.0.8 under 64-bit hosts

Unable to reproduce here. Could you attach a VBox.log of such a session? (close before it crashes your machine).

A minidump would also be useful.

Windows 7 x64 host by the way.

Not reproducable on Vista x64 either. Both Intel machines. It would be useful if you could give some useful information about your environment. (VBox.log would show all that)

We are not able to reproduce this on Vista x64 with AMD machines either. Without feedback, there's little we can do.

Just hit the same problem (probably).

VirtualBox 3.0.8, Windows 2003 R2 x64 host on Core2Duo (curiously, with VT-x/AMD-V listed as enabled), Ubuntu 9.0.4 x32 guest. It worked fine until I enabled second network adapter in a Host-Only mode (the first one did NAT). Then restarted the virtual machine and got BSOD. Someone in the threads mentioned host-only mode, I want to emphasize that this is absolutely crucial.

VBox.log 3.0.10-54097

minidump 3.0.10-54097

Sorry for the delay. I've added minidump and log files using the latest version (3.0.10-r54097).

I've also narrowed it down to the USB drivers. If I disconnect my external USB drive (normally captured by guest) then the VM boots OK.

In 3.0.10 the system freezes while the _host_ is booting. If I unplug the USB drive the host boots OK.

snow00: if you reinstall VirtualBox without the USB drivers, then all problems vanish? The dump doesn't show much other than one cpu crashing or not responding in time.

Yes. I've just tried the following:

1) Uninstall Vbox

a) Host boots OK

2) Install VBox without USB

a) Host boots OK

b) VM boots OK (but can't access USB drive)

3) Reinstall VBox with USB

a) Host freezes during boot* (if USB drive plugged in)

b) Booting VM crashes/freezes host** (unless VT-x enabled)

* - The host boot problem only occur after Windows has popped up "New hardware detected. Installing drivers" when the VM is first run.

** - The VM crashing problem only occurs if VBox captures the USB device. Initially VBox said the USB device was "busy with another request" (or similar wording); and the VM booted OK, but couldn't access the USB drive. I had to reboot the host to get the VM to capture the USB drive, and then it crashed.

For me, the original problem was without anything to do with USB. I did not used USB, not even the USB driver was installed on the system. Since I wrote the bug report, I have upgraded to Win 7 64-bit, I don't know if the problem still exist, but I might have a look at it. Since I changed to VT-x mode, everything is stable, so I didn't care. How can I create minidumb?

BSODs here on 3.0.10 Vista x64 when accessing a USB printer. VT-x/AMD-v mode is not enabled.

How to create a minidump: http://support.microsoft.com/kb/315263

Duplicates: #5190, #5560

Duplicates: #5346

I can reproduce the problem here. Working on a fix.

I can provide 3.1.1 test builds for those interested in testing the fix. Just post a request here.

I'm interested in testing the 3.1.1 fix for this problem. Please point me to it.

I am interested in testing 3.1.1.

You can download a 3.1.1 test build here: http://www.virtualbox.org/download/testcase/VirtualBox-2009-12-11-10-48-30-win-3.1-rel-3.1.1-r55893-MultiArch.exe

This link will only be valid for up to 14 days.

The test build definately resolved the BSOD issue. Great work sandervl73! Unfortunately, the inability to capture USB mass storage remains. Every time after a reinstall or upgrade of VB, on the initial guest boot-up, it starts to install the VirtualBox USB driver, followed by abrutly stopping with a "device unplugged" error. Sub-sequential attempts to attach the USB device just gives the standard "Failed to attach the USB device Generic Mass Storage Device [0100]" error. More details are located here:

http://forums.virtualbox.org/viewtopic.php?f=6&t=24264

But, again, great work on correcting the BSOD. I can be patient until the USB issue is addressed.

Tony

andrews240: that's another (known) problem. The first time you capture a new device you sometimes must close the VM and reinsert the device. Unrelated to this defect.