Cannot discover characteristics of BLE device in Windows 11

Question

We have a BLE device which works fine in Windows 10.
After upgrading to Windows 11 (fresh install, latest Bluetooth drivers from manufacturer) we cannot discover characteristics anymore.
Reproducible on multiple Windows 11 laptops

In our own application, we get an Access Denied when trying to call GetCharacteristicsAsync from a C++/WinRT application.

With the Bluetooth LE Explorer, we also cannot see the available characteristics, but this application just hangs on line 211 of the ObservableGattDeviceService.cs (call to Service.OpenAsync). This program also works fine on same laptop, same device on Windows 10.

I used the busiotools to get an etl file, but this is too big to attach here.

Answer 1

From what you explained, I believe this is a bug.
Try open start and search for feedback and open the Feedback Hub app and report this issue and make sure share steps to reproduce the problem.
Try uninstalling the Bluetooth driver and restart your PC, then run Windows Update and see if there is Bluetooth driver.

Answer 2

Hello PatrickRiphagen,

From what you explained, I believe this is a bug.
Try open start and search for feedback and open the Feedback Hub app and report this issue and make sure share steps to reproduce the problem. Another option would be the Feedback portal of Microsoft at:

https://feedbackportal.microsoft.com/feedback/

Try uninstalling the Bluetooth driver and restart your PC, then run Windows Update and see if there is Bluetooth driver.

-----------------------------------------------------------------------------------------------------------------------------------

--If the reply is helpful, please Upvote and Accept as answer--

Answer 3

Some updates on this issue.

I would indeed still consider this a bug, but it does have some weird items:
Changes we did to at least get some characteristics info.

• Use WINRT_IMPL_CoInitializeEx instead of init_apartment (which does RoInitialize)
• Use COINIT_MULTITHREADED when calling in separate thread, COINIT_APARTMENTTHREADED when in GUI thread
• Update to latest Windows 10 Platform SDK (Windows 11 platform SDK with VS2019 gives linking errors, so that does not seem to work)
• If we get less characteristics then expected, redo FromBluetoothAddressAsync/GetGattServicesAsync. Second time we almost always get our full list of characteristics.

We are not 100% sure which item was the most useful, but neither of them really hurts.

However, we still not always get all characteristics from all services.
We get different results from the first calls to GetCharacteristicsAsync:

• ASyncStatus 2 (Error)
• ASyncStatus 3 (Access Denied)
• No error, just 0 characteristics
• Only characteristis from generic service (Generic Access service)

After item 4 from above (retry), most of the time, we get the characteristics from all services.

We still consider this a workaround, not a fix. Will check the Feedback Hub to see if I can create a bug report from this.

Answer 4

I have experienced an issue with similar symptoms on Windows 10 version 22H2, though I'm not sure if it is the same issue that the original poster had.

In my case, the issue occurred when services with 128-bit UUIDs were locked as "in use", either by another part of my application or by a different application entirely. (It didn't seem to be an issue when I was using a service that had a short UUID.) To solve this within my application, I needed to do delete service to close/dispose each service when I was done using it.

For example, in order to make my application connect to the Bluetooth device immediately, I had added a call to device->GetGattServicesAsync, but then didn't use the resulting service objects. Later, I had been running device->GetGattServicesForUuidAsync to re-retrieve the service, but hadn't closed the original service object. When using the new service object to find characteristics using service->GetCharacteristicsAsync(), it would fail with access denied for 128-bit service UUIDs, returning no characteristics. I resolved this issue by adding a loop to delete (close/dispose) each service after the initial call to device->GetGattServicesAsync.

The issue still occurs when my application tries to access a service while another application is using the same service, though this is much less common to have happen.