Bluetooth disconnect when starting W10 64bit on OS X host

[rcatyvr]

Re: Bluetooth disconnect when starting W10 64bit on OS X host Postby rcatyvr » 17. Dec 2016, 23:45

Problem hunted down and solved for now:

Latest VirtualBox on El Capitan Mac, latest Window 10 from upgrade on 64 bit VM.

Starting the VM caused my host Mac's Bluetooth services to stop and refuse to connect to my keyboard and trackpad and from operating inside/outside of, or after closing the VBox application. It is a BIG problem as the only way to close the VM and restart my host's Bluetooth was to power off then reboot the computer which is an annoying waste of time and can break the HFS+ file system.

Fortunately, I found a wireless Logitech keyboard & mouse handy so I plugged the dongle into my USB hub and was able to continue to troubleshoot without having to crash the system repeatedly just to close the VM

Solution/Work around:

You will need to have at least a wireless or hard wired USB mouse plugged in. Especially if you are using a Mac, be sure that before the Windows VM actually starts to boot that you prevent it from going full screen and you lose the ability to click on the Apple control icon at the top left of the host's screen to do a controlled reboot. If you don't you will probably have to power the unit off the hard way. Note: a similar keyboard setup would help, but is not essential as both in the VM and the host, a functioning mouse can get you through to solution.

1. Confirmed that I had replicable problem--repeatedly from cold start to full power-off crash.
2. Used an archived Win 10 VDI dated September 22, 2016 to confirm the problem originates in fact in Windows, not VBox--no problems seen
3. Went back to the most up-to-date Windows 10 VDI: Services control, I stopped & disabled: a) Bluetooth Handsfree Service, b) Bluetooth Support Service.
4. REBOOTed the Windows VM
5. Tested and had no further interference with the host's Bluetooth hardware.

Problem solved. I would call this a solution, though it is technically a work around, because disabling Windows' bluetooth should be moot. The host shouldn't be able to pass those services to the VM and therefore there is no need for them to even be there/on. However, that as by default they try to start up (and revert to a manual-start service) at boot time, and as it seems that just querying for the hardware is enough to crash the host's own hardware, those services should be disabled.

I don't know how it does it, but have I found out experimentally that in a VBox VM, Windows 10's bluetooth services/hardware layer have been recently changed and are now somehow attempting to control/attach to the host's Bluetooth stack during the client's boot up--causing them to crash and the host loose its hardware bluetooth service. Not supposed to happen, but it does.

A long term solution would be for Oracle to figure how the Win10 VM is trying to access the hosts' hardware and crash it, and prevent it from doing so.

[Socratis]

Let's please continue this discussion in the forums where you also posted this ​https://forums.virtualbox.org/viewtopic.php?f=8&t=76021 and report the outcome here, so as not to bother the developers until we conclude that it's actually a bug. Thanks.

[rcatyvr]

Addendum: I have for the time gone back with an older VBox from the archives because in a test of the solution I mentioned above, while the Windows (with disabled bluetooth) continued to work, when I loaded immediately after ending that session a Xubuntu session, not only did the bluetooth crash, but I lost all all my USB devices (both those directly plugged in and those on a USB port extender) including my old wired mouse.

Everything is working again.

I will be exploring combinations of various older VBox versions and bringing them forward incrementally and with/without EFI/ICH9/disabling USB ports, drive controllers and other similar combination matrixes.