Microsoft stack - verified on Windows XP and Windows 7 64 bit, using InTheHand 3.2, 3.3, and current code in trunk as of this date.
User Trevor posted in the forums the following in thread http://inthehand.com/forums/t/1152.aspx:
"In the interest of making the application as robust as possible I wanted the application to be able to recover from having the PCs bluetooth dongle being pulled out and then reinserted. I can easily detect when this has happened by checking that the BluetoothRadios.PrimaryRadio value is not equal to null. When it is equal to null, I close all the BluetoothClient objects and dispose them.
However when I plug the bluetooth dongle back in to the PC and the application attempts to reconnect, the BluetoothClient.Connect method is never able to reestablish a connection. It throws a WinSock ErrorCode of 10022 (Argument Exception), the arguments have not changed from when the method was successful."
Trevor was very explicit in his description, so I chose to quote him for the primer. My situation is a tad bit different, in that my custom hardware device may power the bluetooth device off or on - this can be easily replicated by running an app using a bluetooth dongle, yanking the dongle, and reinserting it - essentially the same case Trevor is discussing. I have additional information and a repro case to add that points to something InTheHand is doing that causes other apps using bluetooth sockets to fail once an adapter is disconnected/reconnected. These other apps will continue to fail to connect to Bluetooth sockets until the app using InTheHand is closed - after which they will begin to create sockets successfully again.
The attached zip contains two solutions (VS2008), that connects using sockets to a bluetooth device that exposes a SPP profile. The const CONNECT_TO_THIS_DEVICE in both should be replaced with the Int64 version of the Bluetooth device's address, and the device in question should be paired and available. The "BluetoothSocketTestWithInTheHand" solution only uses BluetoothClient (and cleanly closes it) to connect to the remote device and immediately close the connection in response to a button press on the form. Before compiling, place the InTheHand.Net.Personal.dll of your choice in the root of this folder. Assuming all is configured and working properly, you should see a "Connected OK" message - if not, reread the instructions above and fix that issue. After you play with this a few times, remove and replace your bluetooth adapter and press the button again. You will see it fail with error code 10022 'an invalid argument was supplied' repeatedly and forever until you restart the app. Simple repro case. Sadly, it gets worse...
The other folder in the attached code, "BluetoothSocketTestNoInTheHand" needs the same const replaced. This code borrows a bit from InTheHand, but uses only System.Net.Sockets.Socket to make the connection. First, make sure you EXIT the "BluetoothSocketTestWithInTheHand" app. Repeating the steps described above with this exe results in a successful connection after the bluetooth adapter is removed and reinserted (sometimes there is timeout on connect based on how fast the remote device and/or Winsock can be ready to make the next connection, which happens in both samples with my device. Point is, you can connect successfully again after adapter is removed and reinserted). This proves to me that the .NET sockets/winsock can handle this situation just fine and something is broken in InTheHand.
Now, lets run both apps at the same time. Device willing, you should be able to connect/disconnect using both apps when running side by side, so verify this. Now remove the bluetooth dongle and reinsert it while both are running. You will notice that the "BluetoothSocketTestNoInTheHand" will no longer connect and you will see it fail with error code 10022 'an invalid argument was supplied' repeatedly and forever. The same error will happen if you try it on the "BluetoothSocketTestWithInTheHand" app. Simply closing the app using InTheHand will magically allow the socket based project to connect again. This is perhaps the most disturbing part of the bug - running InTheHand will prevent other apps from connecting via sockets if the bluetooth device is power cycled.
I did some initial poking around and found that even cleaning up after the BluetoothWin32Events does not seem to resolve the issue. Issues like this cause me to gravitate towards device handles being passed to notification APIs, but this one doesn't seem to be the culprit. Any ideas?
User Trevor posted in the forums the following in thread http://inthehand.com/forums/t/1152.aspx:
"In the interest of making the application as robust as possible I wanted the application to be able to recover from having the PCs bluetooth dongle being pulled out and then reinserted. I can easily detect when this has happened by checking that the BluetoothRadios.PrimaryRadio value is not equal to null. When it is equal to null, I close all the BluetoothClient objects and dispose them.
However when I plug the bluetooth dongle back in to the PC and the application attempts to reconnect, the BluetoothClient.Connect method is never able to reestablish a connection. It throws a WinSock ErrorCode of 10022 (Argument Exception), the arguments have not changed from when the method was successful."
Trevor was very explicit in his description, so I chose to quote him for the primer. My situation is a tad bit different, in that my custom hardware device may power the bluetooth device off or on - this can be easily replicated by running an app using a bluetooth dongle, yanking the dongle, and reinserting it - essentially the same case Trevor is discussing. I have additional information and a repro case to add that points to something InTheHand is doing that causes other apps using bluetooth sockets to fail once an adapter is disconnected/reconnected. These other apps will continue to fail to connect to Bluetooth sockets until the app using InTheHand is closed - after which they will begin to create sockets successfully again.
The attached zip contains two solutions (VS2008), that connects using sockets to a bluetooth device that exposes a SPP profile. The const CONNECT_TO_THIS_DEVICE in both should be replaced with the Int64 version of the Bluetooth device's address, and the device in question should be paired and available. The "BluetoothSocketTestWithInTheHand" solution only uses BluetoothClient (and cleanly closes it) to connect to the remote device and immediately close the connection in response to a button press on the form. Before compiling, place the InTheHand.Net.Personal.dll of your choice in the root of this folder. Assuming all is configured and working properly, you should see a "Connected OK" message - if not, reread the instructions above and fix that issue. After you play with this a few times, remove and replace your bluetooth adapter and press the button again. You will see it fail with error code 10022 'an invalid argument was supplied' repeatedly and forever until you restart the app. Simple repro case. Sadly, it gets worse...
The other folder in the attached code, "BluetoothSocketTestNoInTheHand" needs the same const replaced. This code borrows a bit from InTheHand, but uses only System.Net.Sockets.Socket to make the connection. First, make sure you EXIT the "BluetoothSocketTestWithInTheHand" app. Repeating the steps described above with this exe results in a successful connection after the bluetooth adapter is removed and reinserted (sometimes there is timeout on connect based on how fast the remote device and/or Winsock can be ready to make the next connection, which happens in both samples with my device. Point is, you can connect successfully again after adapter is removed and reinserted). This proves to me that the .NET sockets/winsock can handle this situation just fine and something is broken in InTheHand.
Now, lets run both apps at the same time. Device willing, you should be able to connect/disconnect using both apps when running side by side, so verify this. Now remove the bluetooth dongle and reinsert it while both are running. You will notice that the "BluetoothSocketTestNoInTheHand" will no longer connect and you will see it fail with error code 10022 'an invalid argument was supplied' repeatedly and forever. The same error will happen if you try it on the "BluetoothSocketTestWithInTheHand" app. Simply closing the app using InTheHand will magically allow the socket based project to connect again. This is perhaps the most disturbing part of the bug - running InTheHand will prevent other apps from connecting via sockets if the bluetooth device is power cycled.
I did some initial poking around and found that even cleaning up after the BluetoothWin32Events does not seem to resolve the issue. Issues like this cause me to gravitate towards device handles being passed to notification APIs, but this one doesn't seem to be the culprit. Any ideas?