Bluetooth LE API does not work after Creators update. RRS feed

  • Question

  • I am using the functions from the WDK UM bluetoothleapis.h

    With this API I've written some Desctop Apps and some UMDF drivers.

    After Creators Update all this Apps and drivers stops working.

    Does anybody know if this is a bug which will be fixed or will this API no longer be supported?

    Is there any other API to access Bluetooth LE devices from Desctop Apps or UMDF drivers?



    Bjoern Kupfer

    Wednesday, May 10, 2017 6:25 PM


All replies

  • Please post a code sample of what is no longer working

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

    Thursday, May 11, 2017 1:59 PM
  • As well, to answer your question about APIs. The Universal (UWP) APIs for Bluetooth also work in desktop, excluding the background namespace. The UWP APIs for Bluetooth have our latest improvements and are recommended over the WDK APIs.
    Thursday, May 11, 2017 2:59 PM
  • The following exsample works before Creators Update when running as Administrator.

    With Creators Update opening the GATT service is okay but the 'BluetoothGATTGetCharacteristics' function returns with E_Fail(0x80004005).

    Same behavior if running inside a UMDF Driver. Opening the service is okay, 'BluetoothGATTGetCharacteristics' function returns with E_Fail.

    #include "stdafx.h"
    #include "ConsoleApplication2.h"
    #include <Setupapi.h>
    #include <Bluetoothleapis.h>

    #ifdef _DEBUG
    #define new DEBUG_NEW

    // Das einzige Anwendungsobjekt
    CWinApp theApp;
    using namespace std;
    const GUID BluetoothInterfaceGUID =
    { 0xb3e57fb6, 0x9231, 0x4f18, { 0xaf, 0xc7, 0x4b, 0x53, 0xf1, 0x33, 0x95, 0x3c }};
    HANDLE GetBLEHandle()
     HANDLE hComm;
     hDI = SetupDiGetClassDevs(&BluetoothInterfaceGUID, NULL, NULL, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT);
     if (hDI == INVALID_HANDLE_VALUE) return NULL;
     did.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
     dd.cbSize = sizeof(SP_DEVINFO_DATA);
     for (DWORD i = 0; SetupDiEnumDeviceInterfaces(hDI, NULL, &BluetoothInterfaceGUID, i, &did); i++)
      SP_DEVICE_INTERFACE_DETAIL_DATA DeviceInterfaceDetailData;
      DeviceInterfaceDetailData.cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);
      DWORD size = 0;
      if (!SetupDiGetDeviceInterfaceDetail(hDI, &did, NULL, 0, &size, 0))
       int err = GetLastError();
       if (err == ERROR_NO_MORE_ITEMS) break;
       pInterfaceDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);
       if (!SetupDiGetDeviceInterfaceDetail(hDI, &did, pInterfaceDetailData, size, &size, &dd))
       hComm = CreateFile(
       if (hComm != INVALID_HANDLE_VALUE)

        registration->NumCharacteristics = 2;
        if (BluetoothGATTGetCharacteristics(hComm, NULL, registration->NumCharacteristics, registration->Characteristics, &(registration->NumCharacteristics), BLUETOOTH_GATT_FLAG_NONE) == S_OK)
         // .....
     return hComm;

    int main()
        int nRetCode = 0;
        HMODULE hModule = ::GetModuleHandle(nullptr);
        if (hModule != nullptr)
            // MFC initialisieren und drucken. Bei Fehlschlag Fehlermeldung aufrufen.
            if (!AfxWinInit(hModule, nullptr, ::GetCommandLine(), 0))
                // TODO: Den Fehlercode an Ihre Anforderungen anpassen.
                wprintf(L"Schwerwiegender Fehler bei der MFC-Initialisierung\n");
                nRetCode = 1;
                // TODO: Hier den Code für das Verhalten der Anwendung schreiben.
            // TODO: Den Fehlercode an Ihre Anforderungen anpassen.
            wprintf(L"Schwerwiegender Fehler: Fehler bei GetModuleHandle.\n");
            nRetCode = 1;
        return nRetCode;

    Bjoern Kupfer

    Friday, May 12, 2017 9:18 AM
  • When the call to BluetoothGATTGetCharacteristics fails, what does hComm represent - a device or service handle ?

    Friday, May 12, 2017 8:42 PM
  • Hello,

    the variable hComm represents a service handle.

    Bjoern Kupfer

    Monday, May 15, 2017 8:17 AM
  • Thanks. This is a known issue that we are actively working on. In the interim as a workaround, you can try to pass in a non-NULL (i.e. valid service uuid and handle) value for PBTH_LE_GATT_SERVICE parameter.

    Of course as mentioned earlier in this post, the recommended way for working with GATT devices going forward are the Bluetooth UWP APIs


    Monday, May 15, 2017 4:36 PM