Crash after connecting USB wifi dongle

[ExGen]

Hi,

I'm getting crashes with my wifi dongle with Vbox 4 and 5.
It's Ralink 802.11n WLAN and i'm currently on 5.0.14.
I also checked other posts and someone had a slightly similar issue but mine wasn't fixed with that.
With USB filters, if I start any VM without dongle connected, and connect dongle before or after OS loads, it crashes.
And if I start VM with dongle connected, I get following error:

The VM session was aborted.
Result Code: E_FAIL (0x80004005)
Component: SessionMachine
Interface: ISession {7844aa05-b02e-4cdd-a04f-ade4a762e6b7}

Also it crashes with selecting USB device from menu.
Ports are USB 3.0 on my laptop and when using filter I don't get a VirtualBox USB.
I also tested it with a USB 2.0 hub which got me same results.
Everything else works fine, only this wifi dongle.

I'll attach log files for E_FAIL error.

[mpack]

Make sure that Hyper-v is disabled on the host.

Your CPU has 4 cores total, so you can't assign 4 cores to the guest. Reduce this to 2.

[ExGen]

Thanks for quick reply.

Hyper-V is already disabled. Reduced to 2 cores and it no longer crashes. Why is that?
But now with filter, nothing happens when I connect dongle (host device manager and guest lsusb).

And with Device->USB menu there are 2 enteries:
Ralink Technology Corp.RT5370 Wireless Adapter [0101], State: Held
Ralink 802.11 n WLAN [0101], State: Captured

When I checked, They're same except first one is without Manufacturer, Serial No and Port
Filter is the fist one.
I get this error after clicking on either of them:

USB device ... is busy with a previous request. Please try again later.
Result Code: E_INVALIDARG (0x80070057)
Component: HostUSBDeviceWrap
Interface: IHostUSBDevice {c19073dd-cc7b-431b-98b2-951fda8eab89}
Callee: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

[ExGen]

Ok back to square one.
I reinstalled VBox and did a reboot now it crashes and I'm getting this again:

The VM session was aborted.
Result Code:
E_FAIL (0x80004005)
Component: SessionMachine
Interface: ISession {7844aa05-b02e-4cdd-a04f-ade4a762e6b7}

Tried 1 and 2 cores. Hyper-V is disabled.
If you found something wrong in logs please tell me.

[mpack]

There is nothing in the log that is useful to me - it is truncated.

You probably have a hardening issue, especially if you use Avira AV. See the hardening issue at the top of this forum. I can't really help much with hardening issues since I don't get the problem myself, and the devs don't provide any information on it.

[ExGen]

What should I do? I'll get you more logs then.
Should I make a ticket? Or maybe discuss this further in that topic?

I attached 3 files:
I first connected the dongle with guest stopped, Then start the guest. Guest runs but in BIOS screen I hear a usb disconnect sound and it crashes. this is Log 1. Then I start guest again and get an E_FAIL -> Log 2.
I disconnect dongle and start guest, wait for loading screen and connect it, crash -> Log 3.

I'm using Kaspersky Internet Security 15.

EDIT: Sorry forgot to attach

[michaln]

If VirtualBox really crashes and it's not something easily reproducible (doesn't sound like it), a crash dump will be required to get anywhere.

[ExGen]

I'm trying to get crash dumps but I think it doesn't exactly crash but exit safely.
After crash WER doesn't give me dumps and VBox won't let me do it with DebugDiag.
What should I do to get them? And please check my logs if possible.

[ExGen]

Still stuck with crash dumps...
WER doesn't save a dump, I assume VBox does exit normally.
I can't attach debugger to VirtualBox.exe.
How to identify source of the problem?

[michaln]

I'm sure it's perfectly reproducible... on one system in the world. I unfortunately can't see anything in the logs, and that includes the slightest hint that any USB device ever got attached to the VM. That's a bit strange.

You won't be able to attach a debugger to the VirtualBox process; you can thank certain "security researchers" for that. It should be possible to get a crash dump if the process crashes. The VBox.log files certainly look like it did, but who knows. Actually, could please you confirm that the VM process (VirtualBox.exe) went away but the service process (VBoxSVC.exe) did not?

Could you please show what 'VBoxManage list usbhost' shows for your device? (No VM needs to be running for that.)

Can you try the same device on a different system, ideally with no 3rd party AV software potentially screwing things up?

[ExGen]

You won't be able to attach a debugger to the VirtualBox process; you can thank certain "security researchers" for that.

So if there's a problem, and it won't crash, what should I do?

VBoxSVC.exe is still there, and VM status is 'Aborted' instead of 'Powered off'.
This is what 'VBoxManage list usbhost' said:

Code: Select all

UUID:               7dc5b221-db75-48a0-9c5b-6bbc58ad20e2
VendorId:           0x148f (148F)
ProductId:          0x5370 (5370)
Revision:           1.1 (0101)
Port:               0
USB version/speed:  2/High
Manufacturer:       Ralink
Product:            802.11 n WLAN
SerialNumber:       1.0
Address:            {4d36e972-e325-11ce-bfc1-08002be10318}\0018
Current State:      Busy

I'll test it on a different system today.
I should mention it works with VMware but I don't like it and prefer VBox.

[michaln]

VBoxSVC.exe is still there, and VM status is 'Aborted' instead of 'Powered off'.

That indicates abnormal termination, most likely VM process crash. Basically it means the VM process went away but didn't cleanly detach from VBoxSVC. If you see no error messages from the VM process, I'd say it crashed.

There should be a crash dump but I honestly don't know what happens if some AV monster is sticking its grubby fingers into the OS (and they are nasty).

Manufacturer: Ralink
Product: 802.11 n WLAN

I see, one of those. It could also be that there's some conflict with the host drivers for that device. When VirtualBox captures USB devices it doesn't care what they are, so the fact you can capture other devices indicates that there's something "special" about the WiFi stick. Possibly its host drivers, possibly something else.

The behavior you're describing is very suspicious because there's no good reason for the VM process to crash until the device is attached, but there's nothing in the log files indicating that it was.