Debugging the Win10 BT stack RRS feed

  • Question

  • Hello,

    I'm using the MSDN Bluetooth Serial HCI Bus driver sample as the basis for an HCI bus driver that I'm developing. To keep things simple, I'm communicating with my BT HW via UART (exactly as the sample intends). I therefore haven't changed the source for the driver. I've built the driver successfully, and devcon reports successful installation.

    However, in the Device Manager, the Bluetooth driver icon appears, but then stops a few seconds later with a yellow warning triangle. Event Viewer reports the following from the :

    Error: The local Bluetooth adapter has failed in an undetermined manner and will not be used.  The driver has been unloaded

    This error is preceded by two identical warnings:

    Warning: A command sent to the adapter has timed out. The adapter did not respond.

    The source for both the error and warnings is BthMini

    The warnings would suggest that my HW device was not responding! However, using my own debug, I can see that my HW is receiving a number of HCI commands from the Win10 BT stack (Reset, Read Local BD Address, etc etc). I can also see that my device is responding with the appropriate HCI responses (Command Complete Success etc etc). Furthermore, using WPP logging and TraceView, I can see that the HCI responses are being sent back to the sample driver correctly. So, apart from the errors from BthMini, everything is looking as I would expect.

    My questions are:

    How do I get more verbose debug from the Win10 BT stack (bthport.sys, bthmini.sys etc)? Can I get WPP/ETW logging working on these?

    Can I gain access to the source for the Win10 BT stack? (Possibly via an NDA with Microsoft?)

    Is there a way to increase the timeout for the BT HCI interface such that very slow HCI transports can be tolerated?



    Tuesday, March 7, 2017 7:53 PM

All replies

  • An update:

    I can get a little debug from bthport using "Microsoft Message Analyzer", which seems to be the ETW logger for system components. Using this, I can see the raw bytes being transferred across the HCI.

    By combining this debug with debug from the UART device, I can see there is a fault in the MSDN BT Serial HCI Bus driver sample. I haven't completely solved it, but the driver is (possibly due to a race condition) requesting to read more data than it should rightly expect. The read never completes, and the rest is history...!

    Tuesday, March 7, 2017 11:29 PM