BleDevice::enumerateBleServices() inconsistent.

[ehardin2]

Derek,

I had noticed this before but I had my hands so full of other problems in my code so I just figured a way past it and didn't let it sidetrack me at the time. Now that I have my code fixed and running, I see this unusual behavior and now it is stopping me.

[Edited] Periodically, BleDevice::enumerateBleServices() -> BleDevice::getGattServices() will error at at the line

    if (HRESULT_FROM_WIN32(ERROR_MORE_DATA) != hr)
{
    stringstream msg;
    msg << "Unable to determine the number of gatt services. Reason: ["
        << Utility::getLastErrorString(hr) << "]";

    throw BleException(msg.str());
}

[Edited] The hr returned error will be ERROR_NOT_FOUND 1168 (0x490) Element not found.

The stopgap measure that I have been using while working on other problems was to connect to my device with MS Bluetooth LE Explorer and then disconnect. Now, when I run my (your) program the services are found and I could proceed.

Any ideas? At the time I couldn't debug it because my Visual Studio 2017 debugger would not let me go beyond "my code". Again, I didn't stop to find out why but now I see that in the WinBleLib Project->Properties->C/C++->General->Support Just My Code Debgging was set to Yes (/JMC). I just turned that off but I had also just run MS BT LE Explorer so I currently don't have the problem happening to try and debug.

I'll let you know next time it happens and if I find anything. In the meantime, if you can think of why BT Explorer clears up the problem, let me know. Also, for the repo, it would be good for future users to have that Support Just My Code Debgging property changed to No

[Added] I notice that ERROR_NOT_FOUND is not mentioned in the doc for BluetoothGATTGetServices function. I see it is a Window System error. Can you think of what might cause this? As I said, if I start MS BT LE Explorer and connect to the BLE device and then quit and then start my program, this error goes away? Any ideas?

[ehardin2]

I did a Wireshark capture again while using MS Bluetooth Explorer. What I see at the end of the session are lines like this: 3691 47.346616 host controller HCI_CMD 42 Sent Disconnect 3693 47.349163 controller host HCI_EVT 33 Rcvd Command Status (Disconnect) 3727 48.142181 controller host HCI_EVT 33 Rcvd Disconnect Complete 3729 48.142344 host controller HCI_CMD 41 Sent Vendor Command 0x0019 (opcode 0xFC19) 3731 48.144081 controller host HCI_EVT 33 Rcvd Command Complete (Vendor Command 0x0019 [opcode 0xFC19])

There is a manufacturer command to turn power off and I was hoping that would do it but that did not work. No matter what I do, once I reboot my machine, I need to run Bluetooth Explorer to get the device back on track. I have tried un-Pairing the device from Windows manually and then re-Pairing manually but that does not fix the problem.

Do you know of any way to disconnect a BLE device? I'm only hoping this will work but it could be that BT Explorer does something else that is fixing the problem

[EDIT] Actually, what I did before was reboot the machine and then un-pair and then re-pair and that did not fix the problem. What I just did was un-Pair, reboot the machine, and then manually re-Pair and now the problem went away.

Since I cannot ask a user to manually un-Pair the BLE device and then re-Pair it before using it again, do you know of a way to Pair and un-Pair or would that require WinRT?

Ed

[DerekGn]

This sounds like some handle is not being disposed correctly or there is a reference to some other ble type hanging around. You should check that any attached event handlers are being disconnected on shut down.

If you check the bluetooth devices in windows control panel you may see that the device is marked as connected after the application code exits.

[ehardin2]

That would have to cached on the device or in Windows, right? Because the problem only happens if I turn off the computer and start it up again. I would think that the device command to PowerOff would clear everything on the device itself but that had no effect. I'll keep poking around. Maybe Debug will tell me right before shutting down.

Ed

At 03:20 PM 8/8/2022, you wrote:

This sounds like some handle is not being disposed correctly or there is a reference to some other ble type hanging around. You should check that any attached event handlers are being disconnected on shut down.

If you check the bluetooth devices in windows control panel you may see that the device is marked as connected after the application code exits.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1208570225view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENDVR3CKNXXGS4TGRKLVYFTXZANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

I believe that it is retained by the OS if the handle is not closed before the application closes. Depends on how the power off works, I would expect that it would disconnect the device. It could be that when the device is powered on again windows maybe reconnecting.

[ehardin2]

Just an update in case it looks familiar or rings a bell.

After rebooting (when my program fails) the Windows registry entry all looks the same as it did before the reboot when things were working.

Debugging the code I see that BleDeviceEnumerator::getBleDevices() will find the device and bleDevice will be instantiated with an InstanceID.

Going into bleDevice.enumerateBleServices() -> when it runs getGattServices -> when it runs HRESULT hr = BluetoothGATTGetServices the hr will be returned with ERROR_NOT_FOUND.

From what I see about the function BluetoothGATTGetServices that is trying to read from the device at this point and not from the Windows registry. I assume that if we have an InstanceID then it can identify that the device is out there and running. So, for some reason the BluetoothGATTGetServices is just not able to communicate with the device to get the list of services. My uneducated opinion would be that this sounds like something on the device that is stopping the communication and not Windows. What is your gut feeling?

At 04:21 PM 8/8/2022, you wrote:

I believe that it is retained by the OS if the handle is not closed before the application closes. Depends on how the power off works, I would expect that it would disconnect the device. It could be that when the device is powered on again windows maybe reconnecting.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1208622864view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENDHXQKDZOFKOX7SPYLVYF24VANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

That sounds about right, AFAIK it works the same as the .net BLE api, which I believe is a wrapper on this API. The .net API only attempts to connect to the actual device when you attempt to enumerate the services, I assume this API is the same.

Does the device have any visual indication that it has an active connection as it might be that there is an existing connection to the device.

It might also be worth tracing the BLE packets to see if it shows anything useful.

[ehardin2]

The device has no visual indicators other than a light to show that it is on. Trying to capture packets is a good idea. I'll give that a try.

Ed

At 01:26 PM 8/9/2022, you wrote:

That sounds about right, AFAIK it works the same as the .net BLE api, which I believe is a wrapper on this API. The .net API only attempts to connect to the actual device when you attempt to enumerate the services, I assume this API is the same.

Does the device have any visual indication that it has an active connection as it might be that there is an existing connection to the device.

It might also be worth tracing the BLE packets to see if it shows anything useful.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1209729302view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENHMU437FYKYIOFROFDVYKPHHANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

Another thing to consider is timing the device might need some time to process the requests. They should be synchronous calls but who knows if the device is able to handle calls that are dispatched in quick succession

[ehardin2]

When it is working I haven't seen any problem with the program making a series of calls. When it is not working, I can be in Debug mode and click on the final GattGetServices and immediately get the ERROR_NOT_FOUND so it is just not communicating. Trying to do a Wireshark capture ends up with nothing showing. Apparently no communication traffic to be traced.

Ed

At 02:43 PM 8/9/2022, you wrote:

Another thing to consider is timing the device might need some time to process the requests. They should be synchronous calls but who knows if the device is able to handle calls that are dispatched in quick succession

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1209801713view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENF4QM7VVJR3VJLXCKLVYKYGLANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

If the bluetooth adapter is a USB based, which most if not all are, you can trace the USB traffic and that will show you the BLE packet data inside the USB requests

[ehardin2]

Yes, it was trying the USBPcap interface in Wireshark and couldn't find any traces that seemed to be for my device or app. I will try some more. Maybe I will set a small loop to issue a bunch of commands before quitting to see.

In the meantime, I was thinking that, if it were something in the device, doing an un-pair, reboot, re-pair wouldn't have anything to do with the device especially since the device would be off this entire time. I'm back to thinking that it has to be something in Windows. I will keep looking.

Ed

At 04:24 AM 8/10/2022, you wrote:

If the bluetooth adapter is a USB based, which most if not all are, you can trace the USB traffic and that will show you the BLE packet data inside the USB requests

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1210403746view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENFIRCDHYLQSN2QWM5TVYNYOVANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[ehardin2]

One thing I did just as a test was to keep the test to the most simple steps. Using the WinBleTest.cpp I let the program run through this part but then stopped it before running any write commands if (BleDeviceEnumerator::getBleDevices().size() >= 1)
{ auto bleDevice = BleDevice(BleDeviceEnumerator::getBleDevices().front()->getInstanceId()); bleDevice.enumerateBleServices(); displayServices(bleDevice); // function above BleDevice::BleGattServices const &services = bleDevice.getBleGattServices(); displayDeviceInformation(services); // INFORMATION Service with Name etc
return 0; }

In the enumerateBleDevices() I put this as the test; I had commented out the throw BleException(msg.str()) in getGattServices and just had it return NULL instead. if (_pGattServiceBuffer == NULL) { cout << "_pGattServiceBuffer is NULL in enumerateBleServices...." << endl; }

I ran Bluetooth Explorer to get things working and the test ran fine. I rebooted and ran again and it failed.

I just wanted to make sure there was no problem being caused by my code to run commands etc.

I'll keep on looking.

Ed

At 04:24 AM 8/10/2022, you wrote:

If the bluetooth adapter is a USB based, which most if not all are, you can trace the USB traffic and that will show you the BLE packet data inside the USB requests

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1210403746view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENFIRCDHYLQSN2QWM5TVYNYOVANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

You should make sure that you are disposing of the handle to the device on shutdown. I have seen this cause issues with other devices in the past.

[ehardin2]

The _hBleDevice is not in scope in main(). Is this the device handle you had in mind? If so, where should I null it out?

Ed

At 10:49 AM 8/10/2022, you wrote:

You should make sure that you are disposing of the handle to the device on shutdown. I have seen this cause issues with other devices in the past.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1210899008view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENFFBRWLMBCS7W4P66TVYPFQXANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[ehardin2]

Also, wouldn't rebooting make a still open device handle moot if there was one? It is rebooting that breaks things. Before rebooting I can run the program over and over without problems.

Ed

At 10:49 AM 8/10/2022, you wrote:

You should make sure that you are disposing of the handle to the device on shutdown. I have seen this cause issues with other devices in the past.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1210899008view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENFFBRWLMBCS7W4P66TVYPFQXANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

I was distracted with something else earlier so I did not look to much at the test code you posted.

The auto bleDevice is scoped between the brackets of the if statement. At the end of the if it should be automatically disposed as its an instance of a HandleWrapper.

If you set a BP on this line you will see the handle being disposed. https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38

So yes an open handle would mean you could only run the test app once.

My only other guess is that the reboot is causing the device pairing info to be lost or invalidated, I am assuming the device is paired/pairable

There is some info on pairing here

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

The BLE apis are not well documented which is a big part of the problem with the apis.

The BLE explorer might be initiating a pairing, I believe this is the case however I have not looked at the BLE explorer code for a number of years so I might be mistaken.

[ehardin2]

I don't think that it is a Pairing issue because, when it is broken, I can see in Windows that it is paired, I then remove it (un-pair) I then re-Pair it, and the app still will not work. If the Pairing info in the registry was changed in any way, one would think that un-pair / re-pair would fix it. However, the odd part is that you need to un-pair before reboot to fix the problem and then re-pair. So reboot without un-pair breaks it while un-pair and then reboot keeps it from breaking ...I'll keep poking at it.

Thanks

At 12:13 PM 8/10/2022, you wrote:

I was distracted with something else earlier so I did not look to much at the test code you posted.

The auto bleDevice is scoped between the brackets of the if statement. At the end of the if it should be automatically disposed as its an instance of a HandleWrapper.

If you set a BP on this line you will see the handle being disposed. https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38

So yes an open handle would mean you could only run the test app once.

My only other guess is that the reboot is causing the device pairing info to be lost or invalidated, I am assuming the device is paired/pairable

There is some info on pairing here

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairinghttps://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

The BLE apis are not well documented which is a big part of the problem with the apis.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1211011499view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENBYNX2CMFTS4PWN2ATVYPPM3ANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[ehardin2]

Correction....while broken, un-pairing and then re-pairing does fix the problem. I could have sworn that was not the case earlier. When people tell me I'm crazy because I will do the same thing over and over expecting different results, well I get the last laugh now ;-)

Ok so it has something to do with pairing I guess. The Bluetooth Explorer is written in WinRT and that is able to pair and un-pair so I'm guessing that is why it will work where the old fashioned C++ cannot.

I hope I don't have to switch to the WinRT :-(

Ed

At 12:13 PM 8/10/2022, you wrote:

I was distracted with something else earlier so I did not look to much at the test code you posted.

The auto bleDevice is scoped between the brackets of the if statement. At the end of the if it should be automatically disposed as its an instance of a HandleWrapper.

If you set a BP on this line you will see the handle being disposed. https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38

So yes an open handle would mean you could only run the test app once.

My only other guess is that the reboot is causing the device pairing info to be lost or invalidated, I am assuming the device is paired/pairable

There is some info on pairing here

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairinghttps://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

The BLE apis are not well documented which is a big part of the problem with the apis.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1211011499view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENBYNX2CMFTS4PWN2ATVYPPM3ANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[ehardin2]

I take it all back. I can't figure out a pattern but it behaves differently at different times. Now, sometimes, Un-Pair / Re-Pair does not fix the problem but running BT Explorer always does.

I've been taking screen shots of the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\BTHLE\Dev_300000e59630 and I have an instance where the program didn't work -> took a screen shot -> ran BT Explorer -> ran the WinBleTest successfully and took a screen shot and then compared the 2. As far as I can see they are identical.

I'm stumped. I was thinking of exporting the key while everything is working and then see if using that to replace the existing one when things stop working makes a difference. Maybe there is something there that I cannot see in comparing the 2 screen shots. Another entry somewhere?

Ed

At 12:13 PM 8/10/2022, you wrote:

I was distracted with something else earlier so I did not look to much at the test code you posted.

The auto bleDevice is scoped between the brackets of the if statement. At the end of the if it should be automatically disposed as its an instance of a HandleWrapper.

If you set a BP on this line you will see the handle being disposed. https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38

So yes an open handle would mean you could only run the test app once.

My only other guess is that the reboot is causing the device pairing info to be lost or invalidated, I am assuming the device is paired/pairable

There is some info on pairing here

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairinghttps://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

The BLE apis are not well documented which is a big part of the problem with the apis.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1211011499view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENBYNX2CMFTS4PWN2ATVYPPM3ANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[ehardin2]

Here is one thing that I did notice.

For the WinBleTest program there is not working and there is not working.

Completely not working is when the BluetoothGATTGetServices() returns ERROR_NOT_FOUND as mentioned above.

However, on Un-Pair / Re-Pair there is NOT a BTHLEDevice key in the registry right below the BTHLE section that is established on Pairing.

After running WinBleTest there is now a BTHLEDevice section that lists 3 or the 5 services. With those 3 services I can get past the BluetoothGATTGetServices() returning ERROR_NOT_FOUND but will error out when trying to write a command with the error that service FFF0 could not be found.

After I run BT Explorer the BTHLEDevice section then lists all 5 of the services. One of the last 2 services is the FFF0 service that contains the FFF4 and FFF5 characteristics needed for reading and writing.

Here is what I see in WinBleTest that may play a part. in your enumerateBleServices you run getGattServices which runs BluetoothGATTGetServices. The MS docs say that "The BluetoothGATTGetServices function gets all the primary services available for a server." Notice "Primary Services".

I find that there is also a BluetoothGATTGetIncludedServices and the docs for that say "The BluetoothGATTGetIncludedServices function gets all the included services available for a given service." Notice "Included" vs "Primary". I have a feeling that the 2 missing services that are not getting put into the registry are "Included" services and, as it turns out, are needed by my device to read and write characteristic values.

I'm going to try and add that call to the WinBleLib and see if that helps.

[EDIT] I believe that BluetoothGATTGetIncludedServices is to get services that are sub-services of a parent service not getting additional parent services......

Ed

At 12:13 PM 8/10/2022, you wrote:

I was distracted with something else earlier so I did not look to much at the test code you posted.

The auto bleDevice is scoped between the brackets of the if statement. At the end of the if it should be automatically disposed as its an instance of a HandleWrapper.

If you set a BP on this line you will see the handle being disposed. https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38https://github.com/DerekGn/WinBle/blob/cef25a498d30002c62a5eb12bbdecdc71db5b6d0/src/WinBleLib/HandleWrapper.cpp#L38

So yes an open handle would mean you could only run the test app once.

My only other guess is that the reboot is causing the device pairing info to be lost or invalidated, I am assuming the device is paired/pairable

There is some info on pairing here

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairinghttps://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

The BLE apis are not well documented which is a big part of the problem with the apis.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1211011499view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENBYNX2CMFTS4PWN2ATVYPPM3ANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

[DerekGn]

I have updated the readme.md on how to get traces from the OS ble implementation, it might show something different between the implementations.

[ehardin2]

Interesting. Thanks, I'll try to implement that tomorrow. I'll let you know.

Ed

At 03:25 PM 8/10/2022, you wrote:

I have updated the readme.md on how to get traces from the OS ble implementation, it might show something different between the implementations.

­ Reply to this email directly, https://github.com/DerekGn/WinBle/issues/16#issuecomment-1211230095view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AIURENAUYY4FASKXI3MJRKDVYQF4RANCNFSM55YW2BEAunsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com