How can I disable Bluetooth connectability?

Question

How can I disable Bluetooth connectability?

Jin Cheng 0

I have a console application that enumerates all Bluetooth radios on the system and finds only one. I then call BluetoothEnableDiscovery(NULL, FALSE) followed by BluetoothEnableIncomingConnections(NULL, FALSE) for that radio. However, BluetoothIsConnectable(NULL) still returns TRUE. test program:

#include <windows.h>
#include <bluetoothapis.h>
#include <stdio.h>
#pragma comment(lib, "Bthprops.lib")
int main()
{
    BLUETOOTH_FIND_RADIO_PARAMS params = {};
    params.dwSize = sizeof(params);
    HBLUETOOTH_RADIO_FIND hFind = NULL;
    HANDLE hRadio = NULL;
    hFind = BluetoothFindFirstRadio(&params, &hRadio);
    if (hFind == NULL)
    {
        printf("BluetoothFindFirstRadio failed: 0x%08X\n",
            GetLastError());
        return 1;
    }
    int radioCount = 1;
    // Check for additional Bluetooth radios.
    HANDLE hNextRadio = NULL;
    while (BluetoothFindNextRadio(hFind, &hNextRadio))
    {
        radioCount++;
        CloseHandle(hNextRadio);
        hNextRadio = NULL;
    }
    printf("Bluetooth radio count: %d\n", radioCount);
    if (radioCount != 1)
    {
        printf("Expected exactly one Bluetooth radio.\n");
        CloseHandle(hRadio);
        BluetoothFindRadioClose(hFind);
        return 1;
    }
    printf("\nInitial state:\n");
    BOOL discoverable = BluetoothIsDiscoverable(NULL);
    BOOL connectable = BluetoothIsConnectable(NULL);
    printf("  Discoverable: %s\n",
        discoverable ? "TRUE" : "FALSE");
    printf("  Connectable : %s\n",
        connectable ? "TRUE" : "FALSE");
    printf("\nDisable discovery:\n");
    SetLastError(ERROR_SUCCESS);
    BOOL ret = BluetoothEnableDiscovery(NULL, FALSE);
    printf("  BluetoothEnableDiscovery(NULL, FALSE): %s\n",
        ret ? "TRUE" : "FALSE");
    if (!ret)
        printf("  GetLastError: 0x%08X\n", GetLastError());
    printf("\nDisable incoming connections:\n");
    SetLastError(ERROR_SUCCESS);
    ret = BluetoothEnableIncomingConnections(NULL, FALSE);
    printf("  BluetoothEnableIncomingConnections(NULL, FALSE): %s\n",
        ret ? "TRUE" : "FALSE");
    if (!ret)
        printf("  GetLastError: 0x%08X\n", GetLastError());
    printf("\nFinal state:\n");
    discoverable = BluetoothIsDiscoverable(NULL);
    connectable = BluetoothIsConnectable(NULL);
    printf("  Discoverable: %s\n",
        discoverable ? "TRUE" : "FALSE");
    printf("  Connectable : %s\n",
        connectable ? "TRUE" : "FALSE");
    CloseHandle(hRadio);
    BluetoothFindRadioClose(hFind);
    printf("\nPress Enter to exit...");
    getchar();
    return 0;
}

console output:


Bluetooth radio count: 1

Initial state:

  Discoverable: FALSE

  Connectable : TRUE

Disable discovery:

  BluetoothEnableDiscovery(NULL, FALSE): FALSE

  GetLastError: 0x80070057

Disable incoming connections:

  BluetoothEnableIncomingConnections(NULL, FALSE): FALSE

  GetLastError: 0x80070057

Final state:

  Discoverable: FALSE

  Connectable : TRUE

Press Enter to exit...

0 comments

1 answer

Your answer

Answer 1

Taki Ly (WICLOUD CORPORATION) 5,630 Microsoft External Staff Moderator

Hello @Jin Cheng ,

Thanks for the detailed test program and console output.

Looking at your run, both calls returned FALSE, which per the documentation means the state was not changed. For BluetoothEnableIncomingConnections, a FALSE return with hRadio = NULL indicates that no radio accepted the state change. BluetoothIsConnectable(NULL) returning TRUE is consistent with that, per BluetoothIsConnectable, it returns TRUE if at least one Bluetooth radio is accepting incoming connections. In other words, the radio does not appear to have moved to a non-connectable state at all.

A few observations:

The ordering precondition already looks satisfied. The documentation requires a radio to be non-discoverable before it can be made non-connectable. Your initial state already reports Discoverable = FALSE, so there is also no discovery state left to change, which may explain the FALSE return from BluetoothEnableDiscovery and suggests the failure is not caused by call ordering.

On GetLastError. The documentation for these functions does not describe GetLastError behavior, so I would suggest not relying on 0x80070057 as the root cause indicator here.

On hRadio = NULL. It may be worth passing the actual handle from BluetoothFindFirstRadio instead of NULL to rule out the "iterate all radios" path and sharing whether the return value differs.

At this point I am not able to confirm whether a programmatic non-connectable state is achievable through BluetoothEnableIncomingConnections on your setup, since the call is returning FALSE consistently. Could you also share the exact Windows build (winver), the Bluetooth adapter model and driver version, and whether the machine is using the in-box Microsoft Bluetooth stack or a vendor stack? That would help clarify whether this is expected behavior or something specific to your adapter and environment.

Possible alternative

If the goal is simply to stop incoming connections, controlling the radio state directly may be a more reliable path than BluetoothEnableIncomingConnections:

Windows.Devices.Radios.Radio with Radio.SetStateAsync set to RadioState.Off

Disabling the adapter (Disable-PnpDevice) or airplane mode, if a full off state is acceptable for your scenario

Please note that both of these turn the radio off entirely rather than keeping it powered but non-connectable. If your scenario requires the radio to stay on while refusing incoming connections, please let me know, that constraint would change the direction of the investigation.

Looking forward to your update. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Jin Cheng 0 Reputation points

2026-08-13T07:21:22.31+00:00

@Taki Ly (WICLOUD CORPORATION)

Thanks for your such prompt response.

It is not that one of my applications expects Bluetooth connectivity to be disabled. Rather, when I was running HLK tests for my Bluetooth device, a test case named “Bluetooth-4.0Specification (2-Machine)” failed with the following error: IsFalse(BluetoothIsConnectable(nullptr)) .I therefore tried to disable Bluetooth connectivity using a console application, but found that I was unable to achieve the desired result.

The Client PC environment used for the HLK test is Windows 11 Home, Build 26100.ge_release.240331-1435, and the Client PC is running in Test Mode. I also tried running the same console application on other PCs in normal environments, and obtained the same result.

As an additional note, regarding the HLK test mentioned above, I have tried several USB Bluetooth dongles, PCIe network adapters, and even the built-in Bluetooth radios on Windows laptops. None of them were able to pass this test, and they all failed with the same error message.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Jin Cheng 0 Reputation points

2026-08-13T07:37:42.5233333+00:00

I also performed the following test: I first called BluetoothEnableDiscovery(NULL, FALSE), then called BluetoothEnableIncomingConnections(NULL, TRUE), and finally called BluetoothEnableIncomingConnections(NULL, FALSE).

In this case, both of the latter two API calls returned TRUE, with the error code being 0. However, when I immediately called BluetoothIsConnectable(NULL) afterward, it still returned TRUE.

I have made sure that there are no other known programs in my environment operating the Bluetooth radio.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-08-14T03:20:04.48+00:00
Hi @Jin Cheng ,

Thank you for the additional context and for running that second test.

In your latest sequence, both BluetoothEnableIncomingConnections calls returned TRUE with error code 0, yet BluetoothIsConnectable(NULL) still returned TRUE. Therefore, my earlier reasoning that the state was not changing because the call returned FALSE no longer explains the behavior.

I should also mention that I have not been able to reproduce this on my side because I do not have access to a suitable Bluetooth radio in my environment.

Since the same behavior occurs across several USB dongles, PCIe adapters, and built-in laptop radios, this may be related to the platform or the HLK test environment rather than a specific device. I would suggest reviewing the test configuration against the following requirements:

Windows HLK prerequisites

Bluetooth Controller Testing Prerequisites

As the failing assertion belongs to an HLK certification test rather than to your own application, this tag is not the right tag for a definitive answer. I would suggest following the official Windows HLK Support guidance so that the appropriate support team can review the test failure.

When reporting the issue, please include the exact test name, the Windows HLK package file, the relevant test logs, and any additional debugging data collected from the failed run. Please let me know if you encounter any difficulty reaching the appropriate support channel.

Thank you.
Jin Cheng 0 Reputation points

2026-08-14T03:31:57.62+00:00

@Taki Ly (WICLOUD CORPORATION)

Thanks for your reply.

I now believe that the actual behavior of the BluetoothEnableIncomingConnections API is inconsistent with its documentation. At the very least, it does not appear to be able to disable connectability.

In the HLK test, I suspect that the test script is calling this API, but this is only a guess at this point. I now need your help to confirm the actual behavior of the above API.

Thank you.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-08-14T08:24:38.8566667+00:00

Hello @Jin Cheng ,

Thank you for clarifying.

Based on the documentation, calling BluetoothEnableIncomingConnections with fEnabled = FALSE should disable incoming connection acceptance, and a return value of TRUE indicates that the state was successfully changed. However, the documentation does not describe the behavior you observed, where the call returns TRUE but BluetoothIsConnectable immediately continues to return TRUE.

I am unable to independently confirm whether this is a platform issue or a documentation issue because I do not have access to a suitable physical Bluetooth environment for equivalent testing. I also cannot confirm whether the HLK test calls this API without access to the test implementation.

Since your results appear inconsistent with the documented behavior, I would suggest reporting the discrepancy through the Feedback option on the BluetoothEnableIncomingConnections documentation. Please include your minimal test program, Windows build, adapter and driver details, and the observed return values so the documentation or product team can investigate.

Please let me know if you encounter any difficulty submitting the feedback.

Thank you.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-08-17T10:44:35.0633333+00:00

Hi @Jin Cheng ,

Do you have any new updates? If you have any question, feel free to reach out. I'm happy to support you.
Jin Cheng 0 Reputation points

2026-08-17T10:55:02.52+00:00

I’ve already created an issue in the feedback channel.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-08-17T11:01:56.02+00:00

Hi @Jin Cheng ,

Thank you for the update and for submitting the issue through the feedback channel.

Since the discrepancy has now been reported for further investigation, please let me know if you have any remaining questions regarding this thread. Otherwise, please confirm whether we can consider this discussion complete and close the case.

If you found my investigation and ongoing support throughout this thread helpful, I’d really appreciate it if you could follow this guide for your confirmation.

Thank you.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-08-19T02:03:14.4133333+00:00

Hi @Jin Cheng ,

Since the issue has been submitted through the feedback channel and there are no further questions at this time, I’ll close this case.

If you receive any updates or need further assistance, feel free to start a new thread and reference this discussion.

Thank you for your cooperation.