A user of 32feet pointed out a change in behaviour between version 3.5 and 4.0. If you disabled the Bluetooth radio after initially getting a reference to the default radio it would still show the Mode as Connectable/Discoverable. I looked into the code and the 3.5 code was doing an additional check – calling BluetoothGetRadioInfo and if this call failed it would return PowerOff. However I then found that this call succeeds and so it still shows an active mode incorrectly. I believe this change probably happened around Windows 8 because the mechanism for disabling the radio changed around this time. However I don’t have a back catalogue of PCs to test this theory.
I had to go back to the drawing board – how do we discover the state of the radio – the API returns successfully and all the flags indicate it is active. The lower level IOCTL call behaves the same too. However if you try and enumerate the BluetoothRadios again* it fails and returns nothing because to this API a disabled radio is the same as no radio at all. So we now have a workaround – when getting the Mode we check to see if there is still a radio present – if not we return PowerOff. Version 4.0.28 includes this fix.
* Enumerating the radios is a bit of a misnomer – although the API introduced back in Windows XP allows for enumerating multiple radio devices, Windows has only ever allowed one at a time – if you attach a second radio it disables the first in device manager. So while you can have multiple radios (with potentially different pairing information) only one can be active at a time.
In The Hand Ltd 