This project has moved. For the latest updates, please go here.

A command sent to the adapter has timed out. The adapter did not respond.

Topics: Bluetooth - Microsoft
Aug 31, 2012 at 9:08 PM

I am experiencing this error on Windows 7. It does not occur under Windows XP. I am using the 3.5 NET version of the in.the.hand.dll / xml files for a windows bluetooth stack


The application connects to a bluetooth enabled device using RFCOMM. The application, run on a desktop, uses polling to scan for our device. When a device is found, it connects, downloads information, then disconnects.

                BluetoothClient client = new BluetoothClient();
                BluetoothDeviceInfo[] devices = client.DiscoverDevices();
                foreach (BluetoothDeviceInfo device in devices)
                    if (device.DeviceName == "XXX")
                        myDevice = device;
            catch { }
            discovering = false;

I call this repeatedly until my device turns up or the maximum time to discover the device expires. Usually the device is discovered in between 40 - 60 seconds. This code worked for approximately 16 communication sessions before failure. We ran four communications, once per hour, over four hours, before the problem manifested itself.

The problem first manifests itself when the device is discovered, but the communication / pairing fails.

                BluetoothClient manager = new BluetoothClient();
                manager.Connect(myDevice.DeviceAddress, BluetoothService.RFCommProtocol);

                // Connect to the serial port service by reading its Stream
                Stream stream = manager.GetStream();

After that, a System event is created with the following information:

A command sent to the adapter has timed out. The adapter did not respond.
BTHUSB, Event 3
The first time it occurred during testing, another event was created indicating the bluetooth driver was unloaded. This particular event log entry has not occurred in subsequent testing. The problem is consistent.
The software is running on a Panasonic PC,
Windows 7 Professional
Service Pack 1
Processor Intel Celeron P4500 @ 1.87 Ghz 1.86 Ghz
Sep 2, 2012 at 7:52 PM

Wierd, haven't seen that before.  So the dongle seems to be crashing.

What dongle/BtRadio?  What's the value of BluetoothRadio.PrimaryRadio.Manufacturer?  Also what's the value of BluetoothRadio.PrimaryRadio.SoftwareManufacturer?

What's the remote device? It could be sending some Bluetooth packet which confuses the dongle.


You are swalling exceptions "catch{ }" Could you at least log them and also set a breakpoint there in case something is being reported.


For the Connect call. As mentioned at :

The Service Class Id should be changed to suit the service you are connecting too, e.g. your custom UUID/Guid, BluetoothService.ObexObjectPush, BluetoothService.PhonebookAccessPse, etc. (Do not use BluetoothService.RFCommProtocol that is pointless, BluetoothClient always uses RFCOMM).

I presume you want BluetoothService.SerialPort  Cant think how that would cause the problem however...


Is the device.Refresh() necessary?

Sep 4, 2012 at 9:22 PM

Bluetooth manufacturer: Broadcomm

Software: Microsoft

Device: Our proprietary device. Working for last seven years.


Catch{}: This was put in to catch the following error:

On Windows XP: system.notimplementedexception

On Windows 7 Professional 32 bit: This method is not implemented in the this class.

Since this was the only error we encountered in four months of testing, I just let it go. It did not affect the overall discovery process. It occurs in about one of fifteen communication sessions.


We discovered a problem with the power settings for the USB hub under Windows 7:

Control Panel --> Search for Power --> Change power plan --> Changed Advanced power settings --> USB Settings --> Set to Disabled

Once this setting was changed, the behaviour improved and the adapter stopped timing out on one of the two machines we are testing Windows 7 with. The second machine is experiencing timeouts, but it appears to be a seperate issue we are continuing to investigate.


We need to use RFCOMM since using a serial port invokes the hardware wizard.

From your documentation:

DeviceName and discovery

Note, due to the way in which Bluetooth device discovery works, the existence and address of a device is known first, but a separate query has to be carried out to find whether the device also has a name.

We do not identify our devices by mac address, we use the device name.

Sep 5, 2012 at 9:14 AM

OK cool.


So if you use:

 manager.Connect(myDevice.DeviceAddress, BluetoothService.SerialPort)

The hardware wizard pops-up? Wierd. That call uses sockets and does not create a virtual COM port so I don't know why that would happen. (Both use SDP also so that's not a difference).

If your remote device has only one service (SPP) active then using RFCommProtocol will work ok. However if the device has more that one service then using RFCommProtocol will mean that BluetoothClient will arbitrarilty chose one of the services -- since they're all match "RFCOMM".


I'm intrigued by the NotSupportedException. I'm presume its not important, but can you get me a full stack trace when it occurs add e.g.

Debug.WriteLine("The exception: " + ex);


Sep 5, 2012 at 2:26 PM

System.NotImplementedException: This method is not implemented by this class.
 at System.Net.EndPoint.Create(SocketAddress socketAddress)
   at InTheHand.Net.BluetoothEndPoint.Create(SocketAddress socketAddress)
   at InTheHand.Net.Bluetooth.Msft.SocketBluetoothClient.DoDiscoverDevices(Int32 maxDevices, Boolean authenticated, Boolean remembered, Boolean unknown, Boolean discoverableOnly, LiveDiscoveryCallback liveDiscoHandler, Object liveDiscoState)\r\n   at InTheHand.Net.Bluetooth.Msft.SocketBluetoothClient.DiscoverDevices(Int32 maxDevices, Boolean authenticated, Boolean remembered, Boolean unknown, Boolean discoverableOnly, LiveDiscoveryCallback liveDiscoHandler, Object liveDiscoState)
   at InTheHand.Net.Bluetooth.Msft.SocketBluetoothClient.InTheHand.Net.Bluetooth.Factory.IBluetoothClient.DiscoverDevices(Int32 maxDevices, Boolean authenticated, Boolean remembered, Boolean unknown, Boolean discoverableOnly)
   at InTheHand.Net.Sockets.BluetoothClient.DiscoverDevices(Int32 maxDevices, Boolean authenticated, Boolean remembered, Boolean unknown)
   at InTheHand.Net.Sockets.BluetoothClient.DiscoverDevices()
   at mycode

Sep 5, 2012 at 4:06 PM

Ok, I managed to catch the error that is disabling the bluetooth dongle. The stack dump is as follows, this is seperate from the above stack dump you asked for. This error, once it occurs, causes the device to not be discoverable. In my code, the device is discovered and passed to the communication routine. When the device attempts to connect to the device, the following occurs:

System.Net.Sockets.SocketException: An invalid argument was supplied 001167FDDC7C:0000000300001000800000805f9b34fb
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at InTheHand.Net.Bluetooth.Msft.SocketBluetoothClient.Connect(BluetoothEndPoint remoteEP)
   at InTheHand.Net.Sockets.BluetoothClient.Connect(BluetoothEndPoint remoteEP)
   at InTheHand.Net.Sockets.BluetoothClient.Connect(BluetoothAddress address, Guid service)

The line in my code this broke on...

manager.Connect(myDevice.DeviceAddress, BluetoothService.RFCommProtocol);

Sep 7, 2012 at 6:06 PM

So for this one a discovery result being passed out of the Microsoft Bluetooth stack is corrupt. The address identifier is something other than Bluetooth. :-(

Sep 7, 2012 at 6:11 PM

So this is a general something bad happened, per MSDN "Plug and Play, driver-stack event, or other error caused failure." see

It would probably be worth trying with another dongle to see if all these issues go away. Maybe try one with CSR silicon.

Sep 7, 2012 at 6:31 PM

This is my final note on this issue in this thread. We have been able to resolve almost all of the problem by slowing down the entire bluetooth communication process. By using Thread.Sleep(...) to give the dongle time to breathe and forcing a 30-second delay between communication sessions, the dongle no longer stops responding to new requests although it does throw the occasional exception. Previously, two Adapter timeout errors in a row would cause the dongle to die and require the PC to be shutdown and restared to get the dongle back up.

I tried the application with another bluetooth library and it exhibited the same behaviour.  I would infer from this the problem is not with your code.  I will be opening a new thread with Microsoft to resolve my remaining issue.

Sep 7, 2012 at 6:42 PM

I did not see your last two notes when I sent my last update. We tried four different bluetooth dongles that had their own drivers. All exhibited the same problem. I am unsure if any of them used CSR silicon. It can't hurt to try...

Thanks for the wiki, I will be talking to Microsoft to see if I can get a better solution than slowing things down.