We have 4 different Windows Mobile devices, and this only happens on one of them. When connecting to a bluetooth device, the program appears to freeze, because AsyncWaitHandle.WaitOne in EndInvoke never becomes signaled, and never returns. When I break into the program, this is the Call stack:

    mscorlib.dll!System.PInvoke.PAL.Threading_Event_Wait(System.IntPtr handle = 2162705)	
    mscorlib.dll!System.Threading.ManualResetEvent.WaitOne() + 0xc bytes	
>   InTheHand.Net.Personal.dll!InTheHand.Net.AsyncResultNoResult.EndInvoke() Line 66 + 0xb bytes	C#
    InTheHand.Net.Personal.dll!InTheHand.Net.Bluetooth.Widcomm.WidcommBluetoothClient.EndConnect(System.IAsyncResult asyncResult = {InTheHand.Net.AsyncResultNoResult}) Line 131 + 0x6 bytes	C#
    InTheHand.Net.Personal.dll!InTheHand.Net.Bluetooth.Widcomm.WidcommBluetoothClient.Connect(InTheHand.Net.BluetoothEndPoint remoteEP = {InTheHand.Net.BluetoothEndPoint}) Line 114 + 0x7 bytes	C#
    InTheHand.Net.Personal.dll!InTheHand.Net.Sockets.BluetoothClient.Connect(InTheHand.Net.BluetoothEndPoint remoteEP = {InTheHand.Net.BluetoothEndPoint}) Line 279 + 0xc bytes	C#
    My code is here in the call stack.

What should I do? What information do you want? This is in the 2.4 beta (actually change set 55008) The device that fails is an HP iPaq 211.

Sorry missed this one.  Presumably the other "completed" indicators behave the same way i.e. a callback is never called, and IsCompleted is false.  Its not just a fault with AsyncWaitHandle??

In Win32 we get some logging on debug/console, but NETCF doesn't have that.  I'm just dashing out just now.  I'll report what diagnostics you can follow later. :-)

Well, I don't know that. When I set a watch on IsCompleted, it tells me "Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.", and it is in Debug mode.

Are you using release 2.4 or downloading the sources from CodePlex?  If you can download the sources and compile the library then we can debug into the library and see why Connect is never returning.  I've been very careful to ensure that Connect always completes even if some error happens, so presumably what's happening is that some Widcomm API is never returning. :-(  We can find out which if we follow the progress in the debugger.  I might have to add some code that detects the non-response if this happens.

You can download the sources via http://32feet.codeplex.com/SourceControl/ListDownloadableCommits.aspx  If you put a breakpoint on all the methods in BluetoothClient with an underscore in them[1], then that will show the progress.  They're called when a step completes.  (You can even step through each (including the original Connect/BeginConnect to see all of what's occurring).

I don't think there's a simple diagnostic process otherwise, I'll think about having that "something caused a timeout" exception with it reporting the current progress.

 

[1] The process is basically:

(Connect -> ) BeginConnect
        -> BeginFillInPort
            ==> FillInPort_ServiceDiscoveryCallback
                -> WidcommRfcommStream.BeginConnect
                     ==> HandlePortEvent
    ==> Connect_FillInPortCallback

I use the source from CodePlex. I currently have Change Set 55008. None of the callbacks are called during Connect. DiscoDevs_InquiryCallback is called during a DiscoverDevices call (which works, and lists all the Bluetooth Devices in range). I just updated to Change Set 55535, and now I get a PlatformNotSupportedException during the BluetoothFactory GetStacks_inLock method. But it allows me to continue, and if I do, I get the behavior listed above.

So if you step from BeginConnect into BeginFillInPort and then into WidcommBtInterface.BeginServiceDiscovery, does m_btIf.StartDiscovery return true?  And then it exits that method?  And then HandleDiscoveryComplete just below is never called?

Is there anything special about this one of the four WM device?  Older Widcomm stack version?

Presumably the same thing occurs straight after a reboot?

 

Presumably the PlatformNotSupportedException is thrown from SocketsBluetoothFactory..ctor when trying to create the MSFT stack.  There was too little init diagnostics in the release version, and hopefully there's not too much in the current version. :-,)   That one appears in Debug mode and when ReportErrors is set.  You could comment out the MSFT stack from the the stack list in BluetoothFactoryConfig.s_knownStacks (or reorder the list).

Yes, the PlatformNotSupportedException is thrown from SocketsBluetoothFactory.

m_btIf.StartDiscovery does return true, and it exits, but HandleDiscoveryComplete does get called. m_btIf.GetLastDiscoveryResult returns success. At the next if, the addresses equal, and it doesn't throw the exception. During the m_btIf.ReadDiscoveryRecords it seems to throw an exception, because it skips SetAsCompleted and jumps to the finally. It does call BeginParameters, and that finishes. I added a Catch Exception before the finally to see the exception, and this is it: "Can't find an Entry Point 'BtIf_ReadDiscoveryRecordsServiceClassOnly' in a PInvoke DLL '32feetWidcomm'." That doesn't make sense to me, the 32feetWidcomm.dll is there, and I'm using the pre-built ones, I haven't modified them.

I tried recompiling the 32feetWidcomm.dll, but it tells me "fatal error C1083: Cannot open include file: 'BtSdkCE.h': No such file or directory".

I tried it on another handheld, and it's doing this too, so I must have been wrong about this being hardware specific.

Yup a couple of things have gone wrong there.  Firstly that I forgot to update the "pre-built" DLLs after I added that new function (BtIf_ReadDiscoveryRecordsServiceClassOnly).  However the managed code is compatible with the older native DLL through WidcommBtIf.ReadDiscoveryRecords catching EntryPointNotFoundException and using the old function in that case.  But that's where the second problem appears to lie; it would appear from your description that NETCF throws a different exception type in that case?? (MissingMethodException??)

So two workarounds until I'm back at my PC tomorrow: 1) download the release (2.4/beta), the DLLs there will have the new function included, or 2) in WidcommBtIf.ReadDiscoveryRecords add another catch clause (or widen the current one).

I'll update the DLLs tomorrow and make some improvements in the code too.  Thanks for helping to debug this. :-)

Yes it is a MissingMethodException. And I'm using the 32feetWidcomm.dll from the beta release and it's working now, thanks.

:-)