none
Bluetooth: BluetoothLEDevice::FromIdAsync() does not complete on 10.0.15063

    Question

  • On Windows 10.0.15063, simple code like the following example gets stuck because FromIdAsync() doesn't complete ( .then(...) part is never executed).

    This code was working fine with earlier version of Windows (10.0.14393), and the similar code, which works on BluetoothDevice class (instead of BluetoothLEDevice)  still works fine with 10.0.15063.

    DeviceWatcher^ leWatcher = DeviceInformation::CreateWatcher(BluetoothLEDevice::GetDeviceSelector());
    leWatcher->Added += ref new TypedEventHandler<DeviceWatcher^, DeviceInformation^>([](DeviceWatcher^, DeviceInformation^ devInfo) {
        auto id = devInfo->Id;
        auto task = BluetoothLEDevice::FromIdAsync(id);
        create_task(task)
    	.then([](BluetoothLEDevice^ leDevice) {
    	    // do something using leDevice
    	});
     }
    

    I looked at the status of the worker threads after this code is executed, and found one them was stuck in the middle of BluetoothLEDevice initialization.

    >	ntdll.dll!_NtWaitForMultipleObjects@20()	Unknown
     	KernelBase.dll!WaitForMultipleObjectsEx()	Unknown
     	combase.dll!DefaultWaitForHandles(unsigned long dwFlags=0x00000008, unsigned long dwTimeout=0xffffffff, unsigned long cHandles=0x00000001, void * * pHandles=0x023ef694, unsigned long * pdwIndex=0x023ef690) Line 39	C++
     	combase.dll!CoWaitForMultipleHandles(unsigned long dwFlags=0x00000008, unsigned long dwTimeout=0xffffffff, unsigned long cHandles=0x00000001, void * * pHandles=0x023ef694, unsigned long * lpdwindex=0x023ef690) Line 124	C++
     	Windows.Devices.Bluetooth.dll!wil::details::WaitForCompletion<struct Windows::Foundation::IAsyncOperation<class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattClientDevice *> *>(struct Windows::Foundation::IAsyncOperation<class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattClientDevice *> *,enum tagCOWAIT_FLAGS,unsigned long,bool *)	Unknown
     	Windows.Devices.Bluetooth.dll!wil::WaitForCompletion<class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattClientDevice *,class Microsoft::WRL::ComPtr<struct Microsoft::Bluetooth::Profiles::Gatt::Interface::IGattClientDevice> >(struct Windows::Foundation::IAsyncOperation<class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattClientDevice *> *,enum tagCOWAIT_FLAGS)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::InitializeGattInterfaceForkbeard(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::InitializeGattInterface(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::InitializeDeviceResources(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Foundation::ActivateInstance<struct IBluetoothBroker>(struct HSTRING__ *,struct IBluetoothBroker * *)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::InitializeDeviceResources(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::RequestAccessSync(unsigned int,unsigned char,unsigned char)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Foundation::GetActivationFactory<class Microsoft::WRL::ComPtr<struct Windows::Devices::Enumeration::IDeviceAccessInformationStatics> >(struct HSTRING__ *,class Microsoft::WRL::Details::ComPtrRef<class Microsoft::WRL::ComPtr<struct Windows::Devices::Enumeration::IDeviceAccessInformationStatics> >)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDevice::RequestAccessSync(unsigned int,unsigned char,unsigned char)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Devices::Bluetooth::BluetoothLEDeviceStatics::FromIdAsync(struct HSTRING__ *,struct Windows::Foundation::IAsyncOperation<class Windows::Devices::Bluetooth::BluetoothLEDevice *> * *)	Unknown
     	Windows.Devices.Bluetooth.dll!Microsoft::WRL::Details::RuntimeClass<struct Microsoft::WRL::Details::InterfaceList<struct Microsoft::WRL::Implements<struct Microsoft::WRL::RuntimeClassFlags<2>,struct Windows::Foundation::ITypedEventHandler<class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattClientDevice *,class Microsoft::Bluetooth::Profiles::Gatt::Interface::GattServicesChangedEventArgs *>,struct IFastRundown,class Microsoft::WRL::FtmBase,class Microsoft::WRL::Details::Nil,class Microsoft::WRL::Details::Nil,class Microsoft::WRL::Details::Nil,class Microsoft::WRL::Details::Nil,class Microsoft::WRL::Details::Nil,class Microsoft::WRL::Details::Nil>,class Microsoft::WRL::Details::Nil>,struct Microsoft::WRL::RuntimeClassFlags<2>,1,0,0>::QueryInterface(struct _GUID const &,void * *)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Internal::AsyncOperation<struct Windows::Foundation::IAsyncOperation<class Windows::Devices::Bluetooth::BluetoothLEDevice *>,struct Windows::Foundation::IAsyncOperationCompletedHandler<class Windows::Devices::Bluetooth::BluetoothLEDevice *>,class Windows::Internal::CMarshaledInterfaceResult<struct Windows::Devices::Bluetooth::IBluetoothLEDevice>,class Windows::Internal::ComTaskPoolHandler,struct Windows::Internal::INilDelegate,struct Microsoft::WRL::AsyncOptions<-1,0,&struct _GUID const GUID_CAUSALITY_WINDOWS_PLATFORM_ID,2> >::_Run(enum Windows::Internal::AsyncStage,long)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Internal::AsyncOperation<struct Windows::Foundation::IAsyncOperation<class Windows::Devices::Bluetooth::BluetoothLEDevice *>,struct Windows::Foundation::IAsyncOperationCompletedHandler<class Windows::Devices::Bluetooth::BluetoothLEDevice *>,class Windows::Internal::CMarshaledInterfaceResult<struct Windows::Devices::Bluetooth::IBluetoothLEDevice>,class Windows::Internal::ComTaskPoolHandler,struct Windows::Internal::INilDelegate,struct Microsoft::WRL::AsyncOptions<-1,0,&struct _GUID const GUID_CAUSALITY_WINDOWS_PLATFORM_ID,2> >::Run(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Internal::ComTaskPool::CThread::_ThreadProc(void)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Internal::ComTaskPool::CThread::s_ExecuteThreadProc(void *)	Unknown
     	Windows.Devices.Bluetooth.dll!Windows::Internal::ComTaskPool::CThread::s_ThreadProc(void *)	Unknown
     	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     	ntdll.dll!__RtlUserThreadStart()	Unknown
     	ntdll.dll!__RtlUserThreadStart@8()	Unknown
    

    Is this a bug of 10.0.15063?  Or am I doing something wrong in my code?

    Tuesday, April 11, 2017 6:59 AM

Answers

  • This issue has been fixed and is available in the latest Windows Insider Fast program flights.  If you are willing, you can validate that this resolves you issues by enrolling into the insider program and installing the latest Fast flight available.  The issue was also rolled out and serviced via Windows Update at the end of June, but is currently an optional update that requires manual installation.

    This posting is provided AS IS with no warranties, and confers no rights.



    Monday, July 10, 2017 6:22 PM

All replies

  • I have same issue. My application cannot work on Windows 10 version 1703 due to without any response after initialized BluetoothLEDevice.

    After I changed the Windows.Devices.Bluetooth.dll to older, and the issue solved.

    I think that is a bug on latest Windows and hope Microsoft can help to fix it.

    Wednesday, April 12, 2017 2:00 AM
  • There have been significant changes to the Bluetooth stack this release, which impact how our APIs interact with each other.  If your application is running as a console application (not a WinRT UWP Store Application), then this is a known issue and we are working on providing a fix.

    In the meantime, this can be worked around by doing either of the following:

    1. Call CoInitializeSecurity in your application's Main function prior to performing any COM or WinRT calls.
    2. Provide an AppId for your executable.

    With both options, it is important to provide Local Service access permission to call into your application. Additionally, the SDDL must be constructed as an Absolute SDDL.  See ConvertStringSecurityDescriptorToSecurityDescriptor and MakeAbsoluteSD for utilities to construct the SDDL object.

    Note that passing in nullptr rather than a SDDL to CoInitializeSecurity will enable the calls to succeed as well, but is less secure than providing an explicit SDDL as it provides access to "Everyone".

    "O:BAG:BAD:(A;;0x7;;;PS)(A;;0x3;;;SY)(A;;0x7;;;BA)(A;;0x3;;;AC)(A;;0x3;;;LS)(A;;0x3;;;NS)"
    
    CoInitializeSecurity(
        absoluteSddl, // Converted from the above string.
        -1,
        nullptr,
        nullptr,
        RPC_C_AUTHN_LEVEL_DEFAULT,
        RPC_C_IMP_LEVEL_IDENTIFY,
        NULL,
        EOAC_NONE,
        nullptr);

    Additionally, if you are deploying and testing your application from Visual Studio, you will need to ensure that you disable the debug host, as it initializes its own settings: https://msdn.microsoft.com/en-us/library/ms185330.aspx.

    Please let me know if you have any questions.


    This posting is provided AS IS with no warranties, and confers no rights.

    Thursday, April 13, 2017 1:23 AM
  • Thank you for the information.

    Yes, my program is not a store app, and adding CoInitializeSecurity() call with the specified SDDL did solve the problem.  Is this change documented anywhere in MSDN?  I'm seeing several API behavior differences in 15063, but cannot find any documentation about them....

    It's very helpful if there's a list of changes...

    Friday, April 14, 2017 5:24 AM
  • Thank you for the information.

    Yes, my program is not a store app, and adding CoInitializeSecurity() call with the specified SDDL did solve the problem.  Is this change documented anywhere in MSDN?  I'm seeing several API behavior differences in 15063, but cannot find any documentation about them....

    It's very helpful if there's a list of changes...

    Glad to hear it worked.  All of the new API functionality has been released in the "What's New" post.  Can you please share what diverged API behavior you are observing, other than the issue here in this thread?

    This posting is provided AS IS with no warranties, and confers no rights.

    Wednesday, April 26, 2017 4:53 AM
  • I'm seeing similar issues from a WinForms application, but obviously calling CoInitializeSecurity is much more tricky from that context - any suggestions @Matthew?
    Thursday, April 27, 2017 11:29 AM
  • I'm seeing similar issues from a WinForms application, but obviously calling CoInitializeSecurity is much more tricky from that context - any suggestions @Matthew?

    Assuming that you have an .EXE for your application, using the AppId is most likely your best approach.  You can quickly test the CoInitializeSecurity method using P/Invoke, but that isn't recommended as a long term solution.

    There are more details at the MSDN link I posted in my earlier post, but here's a rough example of how to define an AppId.  Make sure you generate a new, unique GUID via the VS Tool.  It will also be important to disable the VSHost debug process when launching from VS.

    AccessPermissions"O:BAG:BAD:(A;;CCDCLC;;;PS)(A;;CCDC;;;SY)(A;;CCDCLC;;;BA)(A;;CCDCLC;;;AC)(A;;CCDCLC;;;LS)(A;;CCDCLC;;;NS)" (Note this is the equivalent access permission portion of the SDDL from my CoInit example.  Not specifying LaunchPermissions defaults to: "O:BAG:BAD:(A;;CCDCLCSWRP;;;BA)(A;;CCDCLCSWRP;;;IU)(A;;CCDCLCSWRP;;;SY)").

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{NEW_GUID}]
    @="Winforms Application"
    "AccessPermission"=hex:01,00,04,80,9C,00,00,00,AC,00,00,00,00,00,00,00,14,00,\
      00,00,02,00,88,00,06,00,00,00,00,00,14,00,07,00,00,00,01,01,00,00,00,00,00,\
      05,0A,00,00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,\
      00,00,18,00,07,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,00,\
      00,18,00,03,00,00,00,01,02,00,00,00,00,00,0F,02,00,00,00,01,00,00,00,00,00,\
      14,00,03,00,00,00,01,01,00,00,00,00,00,05,13,00,00,00,00,00,14,00,03,00,00,\
      00,01,01,00,00,00,00,00,05,14,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,\
      20,02,00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\ProcessName.exe]
    "AppID"="{NEW_GUID}"
    As I mentioned earlier, we are clearly aware of the issue and are working on a permanent fix to avoid the need to an app to perform these security initializations.


    This posting is provided AS IS with no warranties, and confers no rights.


    Thursday, April 27, 2017 3:26 PM
  • One thing I noticed was, with earlier Windows (up to 10.0.14393), when I try to access (such as reading characteristics from) device, API calls didn't cause exception.  Instead, they succeeded and returned GattCommunicationStatus::Unreachable status.  But on 15063, same APIs throw exception.

    I hope API documentation to clearly describe how errors are handled (and OS versions to stick with that defined behavior) but current MSDN documents doesn't do that.  They usually doesn't give any more information than API function/parameter names suggest.

    By the way, which "What's New" post are you referring?  Could you give me the URL of that post?

    Thursday, April 27, 2017 3:58 PM
  • One thing I noticed was, with earlier Windows (up to 10.0.14393), when I try to access (such as reading characteristics from) device, API calls didn't cause exception.  Instead, they succeeded and returned GattCommunicationStatus::Unreachable status.  But on 15063, same APIs throw exception.

    I hope API documentation to clearly describe how errors are handled (and OS versions to stick with that defined behavior) but current MSDN documents doesn't do that.  They usually doesn't give any more information than API function/parameter names suggest.

    By the way, which "What's New" post are you referring?  Could you give me the URL of that post?

    In OS version 15603, you should be seeing fewer exceptions when calling these APIs.  Both GattCharacteristic's and GattDescriptor's ReadValueAsync method will continue to return the GattReadResult, which will still return GattCommunicationStatus::Unreachable.  In addition, ATT protocol errors are also captured as part of the GattReadResult, rather than returning an exception, which is exceptionally important when using unpaired LE devices.

    If you are seeing new exceptions in these methods, than that is unintended, and it would be great if you could share the details.

    You can find information on "What's New" here and here.


    This posting is provided AS IS with no warranties, and confers no rights.

    Thursday, April 27, 2017 6:00 PM
  • I'm trying to use the Bluetooth LE APIs via cppwinrt on 10.0.15063, which worked even without the CoInitializeSecurity call. However, I don't get any notifications for changed GATT characteristics.

    I have added the call like you instructed, but it hasn't changed anything. I can discover devices, connect to them and read characteristics, but there are no callbacks.

    I posted some more information at https://github.com/Microsoft/cppwinrt/issues/179.


    • Edited by anlumo Friday, April 28, 2017 2:28 PM
    Friday, April 28, 2017 2:28 PM
  • I'm trying to use the Bluetooth LE APIs via cppwinrt on 10.0.15063, which worked even without the CoInitializeSecurity call. However, I don't get any notifications for changed GATT characteristics.

    I have added the call like you instructed, but it hasn't changed anything. I can discover devices, connect to them and read characteristics, but there are no callbacks.

    I posted some more information at https://github.com/Microsoft/cppwinrt/issues/179.


    I had the exact same problem where ValueChanged notifications didn't fire even though BLE device did send them. Using also cppwinrt in console application. The same code did work before Creators Update. Adding CoInitializeSecurity after cppwinrt initialization did solve the issue.

            winrt::init_apartment();
    
            const char* security = "O:BAG:BAD:(A;;0x7;;;PS)(A;;0x3;;;SY)(A;;0x7;;;BA)(A;;0x3;;;AC)(A;;0x3;;;LS)(A;;0x3;;;NS)";
            PSECURITY_DESCRIPTOR pSecurityDescriptor;
            ULONG securityDescriptorSize;
    
            if (!ConvertStringSecurityDescriptorToSecurityDescriptor(
                security,
                SDDL_REVISION_1,
                &pSecurityDescriptor,
                &securityDescriptorSize))
            {
                return FALSE;
            }
    
            // MakeSDAbsolute as defined in
            // https://github.com/pauldotknopf/WindowsSDK7-Samples/blob/master/com/fundamentals/dcom/dcomperm/SDMgmt.Cpp
            PSECURITY_DESCRIPTOR pAbsoluteSecurityDescriptor = NULL;
            MakeSDAbsolute(pSecurityDescriptor, &pAbsoluteSecurityDescriptor);
    
            HRESULT hResult = CoInitializeSecurity(
                pAbsoluteSecurityDescriptor, // Converted from the above string.
                -1,
                nullptr,
                nullptr,
                RPC_C_AUTHN_LEVEL_DEFAULT,
                RPC_C_IMP_LEVEL_IDENTIFY,
                NULL,
                EOAC_NONE,
                nullptr);
            if (FAILED(hResult))
            {
                return FALSE;
            }


    • Edited by Iltis Tuesday, May 09, 2017 10:20 AM
    Tuesday, May 09, 2017 10:19 AM
  • Unfortunately, I'm in a DLL and not an EXE file, so I can't call CoInitializeSecurity (I tried, but I only get the error that it's too late to call it). However, setting the AppId via the registry *did* fix the issue. Thank you for the help!
    Monday, May 15, 2017 1:11 AM
  • I´m trying to fix the issue via the registry solution, but it didn`t work. I have a c# Project, which has no problems before the update to 15063.

    I add in a registry a new entry with the generated AppID and disable the "Visual Studio hosting process", but when i start the project and call "BluetoothLEDevice.FromBluetoothAddressAsync" nothing happens.

    Did i forget something ?

    Tuesday, May 16, 2017 8:31 AM
  • Sorry but no one can help me ? I´m despairing.

    In the Visual Studio C# Project I have only change in AssemblyInfo.cs the GUID and set the ComVisible to true.

    Is there a mistake or did I forgot something ?

    Thursday, May 18, 2017 9:29 AM
  • I found my mistake. I forgot to enter the correct process name in the registry. This is very stupid :-)
    Friday, May 19, 2017 10:46 AM
  • Hey Matthew.

    We just got the Creators Update on one of our customer PCs, and our tool stopped working. Upon investigation, same issue as above.

    Only that in our case it's a WinForms app calling a Portable Library.

    Is there a workaround like the above for .NET world as well?

    Saturday, June 10, 2017 2:07 AM
  • sorry just saw the app id for Winforms workaround below. Will try it

    Do you guys have an ETA for the fix?

    thanks

    Saturday, June 10, 2017 2:11 AM
  • Workaround fixed it - Please advise on ETA for fix.

    thanks

    Saturday, June 10, 2017 9:32 PM
  • Hi anlumo,

    I have same problem with a DLL, with no progress,

    could you please post the register solution? what REG_BINARY do you use for AccessPermission? 

    do you have any other Keys with your AppID? AuthenticationLevel? 

    Thanks in advance

    Thursday, June 15, 2017 7:07 PM
  • Anyone has resolved the problem via the registry solution when the access is through a DLL? Wich secure descriptor have you use? 
    I can create the services, subscribe to characteristics but with no notification from them...
    When the access is via DLL do I have to put both AppIDs with permisions in the registry, .EXE and .DLL?
    Wich registry keys have I to use?

    Thanks for your support...
    Friday, June 16, 2017 10:38 AM
  • I'm having what appears to be a related issue.  I'm running a desktop app written using managed C++ and the SetupDI API.  The call to ::CreateFile() with the path to a custom service now results in an ACCESS DENIED error when it did not previously.  Other services like "device id" work as before.  The registry hack doesn't seem make a difference although in my case the BLE calls are inside a DLL (I tried both the exe name and the dll name with no success).

    Any thoughts if the problems I'm experiencing are related?  Ideas for a fix?  

    This app was written when there was no .NET BLE API for the desktop and I haven't kept up.  Is there now?  Are there any plans for one?

    Monday, June 19, 2017 1:57 PM
  • I'm having what appears to be a related issue.  I'm running a desktop app written using managed C++ and the SetupDI API.  The call to ::CreateFile() with the path to a custom service now results in an ACCESS DENIED error when it did not previously.  Other services like "device id" work as before.  The registry hack doesn't seem make a difference although in my case the BLE calls are inside a DLL (I tried both the exe name and the dll name with no success).

    Any thoughts if the problems I'm experiencing are related?  Ideas for a fix?  

    This app was written when there was no .NET BLE API for the desktop and I haven't kept up.  Is there now?  Are there any plans for one?

    Hi Marco,

    Have you solve the problem of access BLE inside a DLL? Your configuration is very close of mine and I have no solution yet, any advice will be welcome...

    thanks

    Thursday, June 22, 2017 7:13 AM

  • Hi Marco,

    Have you solve the problem of access BLE inside a DLL? Your configuration is very close of mine and I have no solution yet, any advice will be welcome...

    thanks

    Sorry, Raster.  No solution yet.  -Marco
    Thursday, June 22, 2017 1:26 PM
  • This issue has been fixed and is available in the latest Windows Insider Fast program flights.  If you are willing, you can validate that this resolves you issues by enrolling into the insider program and installing the latest Fast flight available.  The issue was also rolled out and serviced via Windows Update at the end of June, but is currently an optional update that requires manual installation.

    This posting is provided AS IS with no warranties, and confers no rights.



    Monday, July 10, 2017 6:22 PM
  • @Marco,

    All of the WinRT Windows.Devices.Bluetooth* APIs are usable from a .NET application, and have significantly more functionality available (i.e. Advertisements, Gatt Server, removed requirements for pairing the device).  We recommend that all applications use these APIs, and there should be no need to use the Bluetooth Win32 APIs going forward in a Desktop or .NET environment.


    This posting is provided AS IS with no warranties, and confers no rights.


    Monday, July 10, 2017 6:26 PM
  • Thanks. I am working to build another app that uses the .NET API.

    In the meantime, I've installed the latest Windows and seems to only partially fix this problem.  The problem now (as others have noted above) is the characteristics don't behave in the same way.  While I am getting the notification of changes, the notification doesn't seem to be pushing the new value of the characteristic into the cache.  A call to BluetoothGATTGetCharacteristicValue() doesn't retrieve the updated value unless I supply a flag of BLUETOOTH_GATT_FLAG_FORCE_READ_FROM_DEVICE which in my case i problematic.

    Is this a known issue?

    thanks,

    marco

    Tuesday, July 11, 2017 5:24 PM
  • Thanks. I am working to build another app that uses the .NET API.

    In the meantime, I've installed the latest Windows and seems to only partially fix this problem.  The problem now (as others have noted above) is the characteristics don't behave in the same way.  While I am getting the notification of changes, the notification doesn't seem to be pushing the new value of the characteristic into the cache.  A call to BluetoothGATTGetCharacteristicValue() doesn't retrieve the updated value unless I supply a flag of BLUETOOTH_GATT_FLAG_FORCE_READ_FROM_DEVICE which in my case i problematic.

    Is this a known issue?

    thanks,

    marco

    Thanks for reporting this.  Today, characteristic Notification values sent from a subscribed characteristic are not cached, only the result of a call to BluetoothGATTGetCharacteristicValue or GattCharacteristic.ReadValueAsync will be cached (assuming the read is successful).  We will take a look at restoring this behavior for a future release, but in the meantime, I would recommend caching the value of the notification within your application.


    This posting is provided AS IS with no warranties, and confers no rights.

    Wednesday, July 12, 2017 4:32 PM
  • Thanks for the reply.  Unfortunately, that doesn't quite work.  The problem is that (at least in the SetupDI native APIs), the notification doesn't come with the data that was changed.  This current behavior means I have to read from the device, the data being sent twice.  In our application, there is quite a lot of data being sent.  There is sufficient bandwidth for the data to be sent once, but not twice.

    I'm currently working on a rewrite using the .NET API.  There is a bit of a learning curve and I'm not sure how long it will take me.  Currently, I can't get the characteristic notifications to work at all.  There is some evidence from the above comments that this is still a problem but it's also quite likely that I'm doing something wrong.

    marco

    Wednesday, July 12, 2017 5:07 PM
  • Hello, Matthew,

    We have a Classic desktop DLL which uses UWP calls to operate Bluetooth LE devices. With the optional patch things kind of improved: Bluetooth LE devices properly create the GattDeviceService and we can enumerate and access GattCharacteristics of the devices. The code can properly write to writeable GattCharacteristics (with the connected device reacting to the writes).

    Problem is the read GattCharacteristics receive no data whatsoever. The GattCharacteristic is one with notifications and notifications are set for the characteristic:

    GattCharacteristic.WriteClientCharacteristicConfigurationDescriptorAsync(
    GattClientCharacteristicConfigurationDescriptorValue.Notify);

    The GattCharacteristic.ValueChanged event listener does not seem to be called at all.

    Note, that UWP application which uses the same code works fine. The same classic desktop DLL on Anniversary update, works fine, too.

    Are you aware of such an issue (even after the patch)?








    • Edited by Kamka Wednesday, August 23, 2017 9:59 AM
    Thursday, July 13, 2017 9:47 AM
  • Kamka,

    I appear to be facing a similar problem in this thread.  The fact that the same code works as a UWP is interesting.  You may want to have a look there in case I get an answer.

    cheer,

    marco

    Thursday, July 13, 2017 1:35 PM
  • Hello, Mathew,

    We have a Classic desktop DLL which uses UWP calls to operate Bluetooth LE devices. With the optional patch things kind of improved: Bluetooth LE devices properly create the GattDeviceService and we can enumerate and access GattCharacteristics of the devices. The code can properly write to writeable GattCharacteristics (with the connected device reacting to the writes).

    Problem is the read GattCharacteristics receive no data whatsoever. The GattCharacteristic is one with notifications and notifications are set for the characteristic:

    GattCharacteristic.WriteClientCharacteristicConfigurationDescriptorAsync(
    GattClientCharacteristicConfigurationDescriptorValue.Notify);

    The GattCharacteristic.ValueChanged event listener does not seem to be called at all.

    Note, that UWP application which uses the same code works fine. The same classic desktop DLL on Anniversary update, works fine, too.

    Are you aware of such an issue (even after the patch)?








    Kamka,

    We'll take a look at the issue.  Can you please confirm if using one of the above work-arounds listed above unblocks the notification callback?


    This posting is provided AS IS with no warranties, and confers no rights.

    Thursday, July 13, 2017 6:27 PM
  • We are developing a standalone application using the Unity game engine. We made a classic DLL plugin that allows the Unity app to communicate over BLE. I can confirm that we were not getting notifications from a characteristic before making the registry changes described here, but we are getting them after making those changes.

    To reiterate:
    We build the Unity project to a standalone executable.
    Running the executable as-is, no notifications from BLE.
    After registering an AppID and AccessPermissions for that executable, we get notifications.

    Friday, July 14, 2017 3:11 PM
  • I can also confirm that adding the the permission entries in the registry enables the notification.

    marco

    Friday, July 14, 2017 3:38 PM
  • I can also confirm that adding the the permission entries in the registry enables the notification.

    marco

    Thanks Marco,

    We'll take a look at the issue.


    This posting is provided AS IS with no warranties, and confers no rights.

    Monday, July 17, 2017 3:06 PM
  • I also have the same problem using the UWP BLE API from a desktop application.

    I first had the initial problem described here (FromIdAsync) and could solve it using :

    CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, Security.RpcAuthnLevel.Default, Security.RpcImpLevel.Identify, IntPtr.Zero, Security.EoAuthnCap.None, IntPtr.Zero);

    Now (my system was probably updated since) I have the problem at the characteristic subscription if I remove the CoInitializeSecurity : I don't get the notifications. Everything still works fine using the CoInitializeSecurity workaround.

    This was just for your information. I have additional questions :

    Is the bug related to the execution environment or to the development environment ? In other words, do I have to keep the workaround in my application even when the bug is fixed ? (to support non up-to-date systems).

    If I run my application as a service, I get a DevicePairingResultStatus.AccessDenied on device pairing (using Windows.Devices.Enumeration.DeviceInformationCustomPairing). Is this also related to this bug ? Can it be solved through CoInitializeSecurity ?

    Thanks for your help.



    Monday, July 24, 2017 1:23 PM
  • Hello all,

    I have been trying to write GATT characteristic to my BLE Device, with the new Windows build 1703 breaking my app on .NET. But no luck so far. As with the case with fellow developers here, the UWP version of my App works fine.

    When I do this:

    status = await btleDevice.GetGattService(charAsGuid.serviceGuid).GetCharacteristics(charAsGuid.guid).FirstOrDefault().WriteValueAsync(managedArray.AsBuffer(), GattWriteOption.WriteWithoutResponse);

    I get the following:

    Exception thrown: 'System.UnauthorizedAccessException' in MetawearWpfWrapWin32.exe
    Error writing gatt characteristic: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
    The Registry entry and disabling VS debug hosting did not solve my problem. Any advice would be appreciated. Thanks


    Tuesday, July 25, 2017 6:56 PM
  • Same update has broken my App too.I think program can not read any values from HRM Device.

    Waiting for some ways to fix it.

    Wednesday, July 26, 2017 12:45 PM
  • Same update has broken my App too.I think program can not read any values from HRM Device.

    Waiting for some ways to fix it.

    We are also facing similar issues. Firstly, the app doesn’t receive notifications at all. After making registry changes, the “Console App” seems to be working fine. Same code from WPF Desktop application stops receiving notifications after successfully receiving few times. If we Dispose GattDeviceService and recreate, the app gets few more notifications. The cycle continues.

    Help in resolving this issue is highly appreciated.


    Tuesday, August 15, 2017 4:22 PM
  • Kamka,

    We'll take a look at the issue.  Can you please confirm if using one of the above work-arounds listed above unblocks the notification callback?


    This posting is provided AS IS with no warranties, and confers no rights.

    Hi, Matthew,

    Thanks for continuing support in this thread!

    I tried setting AppID and calling CoInitializeSecurity but issue still occurs (running outside of VS). The CoInit... call fails with 0x80010119 (RPC_E_TOO_LATE) - this is a Windows Forms C# app (I try calling it first thing in Main()).

    If I can provide any more info, do PM me.

    Best,
    Kamen


    • Proposed as answer by Venkata Thumu Monday, August 21, 2017 2:11 PM
    • Unproposed as answer by Venkata Thumu Monday, August 21, 2017 2:11 PM
    • Proposed as answer by Venkata Thumu Monday, August 21, 2017 2:17 PM
    • Unproposed as answer by Venkata Thumu Monday, August 21, 2017 2:18 PM
    • Edited by Kamka Wednesday, August 23, 2017 10:00 AM
    Monday, August 21, 2017 1:02 PM
  • Kamka,

    We'll take a look at the issue.  Can you please confirm if using one of the above work-arounds listed above unblocks the notification callback?


    This posting is provided AS IS with no warranties, and confers no rights.

    Hi, Mathew,

    Thanks for continuing support in this thread!

    I tried setting AppID and calling CoInitializeSecurity but issue still occurs (running outside of VS). The CoInit... call fails with 0x80010119 (RPC_E_TOO_LATE) - this is a Windows Forms C# app (I try calling it first thing in Main()).

    If I can provide any more info, do PM me.

    Best,
    Kamen

    Hi Kamen, I have experienced exactly same issue. You can give a quick try of the following:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{C6BFD646-3DF0-4DE5-B7AF-5FFFACB844A5}]
    "AccessPermission"=hex:01,00,04,80,9c,00,00,00,ac,00,00,00,00,00,00,00,14,00,\
      00,00,02,00,88,00,06,00,00,00,00,00,14,00,07,00,00,00,01,01,00,00,00,00,00,\
      05,0a,00,00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,\
      00,00,18,00,07,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,00,\
      00,18,00,03,00,00,00,01,02,00,00,00,00,00,0f,02,00,00,00,01,00,00,00,00,00,\
      14,00,03,00,00,00,01,01,00,00,00,00,00,05,13,00,00,00,00,00,14,00,03,00,00,\
      00,01,01,00,00,00,00,00,05,14,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,\
      20,02,00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\YOURAPP.exe]
    "AppID"="{C6BFD646-3DF0-4DE5-B7AF-5FFFACB844A5}"

    1. Copy above content to a text file.

    2. Replace 'YOURAPP.EXE' with your executable name

    3. Optionally replace GUIDs (I have created a new one for you)

    4. Save text file with an extension as .reg

    5. Double click on the file. 

    6. You would see a message 'The Keys and values contained in ..... .reg have been successfully added to the registry.'

    With this, I don't need to call CoInitializeSecurity from my app.

    Hope this helps.


    Monday, August 21, 2017 2:27 PM
  • Hey, Venkata,

    Manually setting the permissions did the trick!!! Many, many thanks!!!

    Now we only need another patch from Matthew :)

    Just one question: in our case the .NET code has a C-style wrapper DLL which allows different frameworks to call it. So, imagine Java/Delphi->C-style wrapper->.NET code. Which AppId (DLL?) shall we grant access to? As a note - the AccessPermissions reg entry works when integrating the .NET DLL directly in a Windows Forms app. Still need to try it with a Java/Delphi->C-style DLL->.NET DLL setup :)

    Best,
    Kamen






    • Edited by Kamka Wednesday, August 23, 2017 9:59 AM
    Tuesday, August 22, 2017 11:58 AM
  • Could you please tell what is the Windows Update KB fix number?

    Thanks, Julio

    Tuesday, August 22, 2017 6:02 PM
  • Hey, Venkata,

    Manually setting the permissions did the trick!!! Many, many thanks!!!

    Now we only need another patch from Mathew :)

    Just one question: in our case the .NET code has a C-style wrapper DLL which allows different frameworks to call it. So, imagine Java/Delphi->C-style wrapper->.NET code. Which AppId (DLL?) shall we grant access to? As a note - the AccessPermissions reg entry works when integrating the .NET DLL directly in a Windows Forms app. Still need to try it with a Java/Delphi->C-style DLL->.NET DLL setup :)

    Best,
    Kamen





    Hi Kamen,

    Glad that it worked for you. I would say, you have to set permission for your executable (.exe) whether it is a .Net app or Native app. One huge issue I am currently stuck on is Indications/Notifications stopped, with no apparent reason, after successfully receiving them for sometime.

    With our device, we write a command to a characteristic and we expect response as an Indication from a different characteristic which our app listens on. A sample WPF App receives few Indications after startup and stops receiving later on. If I dispose service and connect again, without closing the app, it receives few more indications. The same code from Console application receives many more Indications but eventually it stops receiving them as well. I can always write the data successfully to a characteristic though.

    I am hopeful that we get a fix from Microsoft soon. I am giving you heads up as you might face similar issue.

    Regards,

    Venkat

    Tuesday, August 22, 2017 6:56 PM
  • Same update has broken my App too.I think program can not read any values from HRM Device.

    Waiting for some ways to fix it.

    We are also facing similar issues. Firstly, the app doesn’t receive notifications at all. After making registry changes, the “Console App” seems to be working fine. Same code from WPF Desktop application stops receiving notifications after successfully receiving few times. If we Dispose GattDeviceService and recreate, the app gets few more notifications. The cycle continues.

    Help in resolving this issue is highly appreciated.


    I've got the same issues here.

    In a WPF desktop app I can list the services and characteristics but not receive valuechanged events.

    If I add the CoInitializeSecurity  call, I receive a few events then it stops.

    Could you give us the Kb number of the fix please ? 

    Thanks in advance

    Friday, August 25, 2017 3:29 PM
  • Same update has broken my App too.I think program can not read any values from HRM Device.

    Waiting for some ways to fix it.

    We are also facing similar issues. Firstly, the app doesn’t receive notifications at all. After making registry changes, the “Console App” seems to be working fine. Same code from WPF Desktop application stops receiving notifications after successfully receiving few times. If we Dispose GattDeviceService and recreate, the app gets few more notifications. The cycle continues.

    Help in resolving this issue is highly appreciated.


    I've got the same issues here.

    In a WPF desktop app I can list the services and characteristics but not receive valuechanged events.

    If I add the CoInitializeSecurity  call, I receive a few events then it stops.

    Could you give us the Kb number of the fix please ? 

    Thanks in advance

    We have a similar problem. Our setup is a little different. We access BTLE services inside a DLL.
    We have solved the notifications problem via the register (many thanks to all of you that had posted your solutions).
    Now we receive notifications (we use various devices, one of them is a HRM as you). We subscribe to the notifications and it works, but if the device loses its connection we dont receibe notifications any more (even if the device is connected again).
    We try to use a "PnPObjectWatcher" to monitorice the "System.Devices.Connected" property and try to recreate the services, as this works for us too, but the "watcher" never notify us the connection loss. I don't know if this issue is relative or not.. we are now blocked with this connection loss notifications...

    All of this, works fine before the update (1703).

    Wednesday, August 30, 2017 9:22 AM
  • Where can I download the fix? None of the workarounds posted here worked for me.
    Thursday, August 31, 2017 9:21 AM
  • Another relaitve issue is the device status in Bluetooth Windows Panel.
    It seems that when a device loses connection, it changes its state to "Paired" instead of "Connected". This looks right, but if you connect the device again, its status do not change to "Connected" again, ...never...
    More over, if you access the "System.Devices.Connected" property in the "Device Container" it is "false" and there is nothing you can do to change it. The only way is to remove the device and add it again to Windows Bluetooth devices... 
    That sounds wrong to me, and it's causing troubles to the devices status management of our application...

    Anyone has similar problems with this?

    Thanks in advance
    Thursday, August 31, 2017 10:05 AM
  • This post has been marked as solved and does'nt seem to be read anymore ... I created a new one about this issue ;

    https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4853e06b-ed2b-4587-9f87-deee2ae1b771/bluetooth-problems-since-creators-update-no-valuechanged-events-for-unpaired-ble-devices?forum=wdk

    Wednesday, September 06, 2017 9:19 AM
  • Thank you Matthew. My program did not work on windows 10 built 15063.608. I followed your instructions and now it work perfect!. Now I install built 15063.674 update and my program continue working.
    Thursday, October 12, 2017 3:28 PM
  • I have updated windows to the latest version 1709, build 16299.192. Windows insider updates are available for me as all, and tells me my system is up-to-date. Yet, I still can't get it to work with the information provided here.

    Can you please provide some more details about the solution:

    1. What windows version and build includes the fix for this issue.

    2. Is it possible to get a link to a direct download of a fix package?

    Any help would be greatly appreciated 

    Tuesday, January 30, 2018 4:30 PM