ActiveSync slow to accept connections under Windows 10

Mar 3 at 8:36 PM
I've had very good success with the Desktop Communication Library under Windows XP and Windows 7 for an application running at a few hundred sites in a medical scenario. And while Windows 10 x64 appears to support the WMDC just fine, I'm finding that after a successful connection with a device (I'm using guest mode), WMDC (or possibly the Desktop Communication Library) is slow to enter listen mode again for another connection.

I can see the events fire as the library emits a status line into the debugger's output pane ("Listen", "Active", "Disconnect", etc). When "Listen" appears, connecting a device yields a good connection and followup processing. But after that good connection, by looking at the debugger's output window, that "Listen" state does not occur again immediately. Connecting a device during this time will not achieve a connection. When "Listen" does appear again, the device will connect to the PC just fine. It appears the re-"Listen" time can be 3-5 minutes or more, which makes for a bad situation when the customer expects an reasonably fast device-to PC-connection to occur.

Again, this same exact app performs well under Windows XP and Windows 7. With late versions of Windows 10 (1607) and with WMDC 6.1, when used with the latest Desktop Communication Library, ActiveSync is slow to prepare itself for subsequent connections. If I terminate my app, and perform a 10 times connect test with a device, ActiveSync immediately connects the device to the PC all ten times, with no delay seen.

If anyone has seen or understands this issue and might have a workaround (code or otherwise), please let me know. Thanks.
Apr 11 at 11:42 PM
I think I'm seeing similar issues, cbc700. I haven't tested different OS versions yet, for me the issue is with the mobile hardware. Old MC3090 running CE 5.0 seems to connect and disconnect reliably, both with WMDC and my software. But new MC3200 running Mobile 7.0 has big issues with my app using OpenNetCF Desktop.

OpenNETCF Desktop seems to lose synchronization with the device after a disconnect, and interferes with WMDC until my app closes.
Jun 4 at 4:52 PM
Hello Tim:

I read your details. I'm not familiar with that hardware so I cannot add anything to that. My situation was specific to Windows 10. No troubles seen on 7 or XP. It might be prudent for you to instrument Desktop.Communication with a good deal of logging using a system that won't get in the way (I use SmartInspect). That will allow you to see all that is happening and perhaps help to pin it down.

I could never get around that problem. I chose to add a method to ActiveSync that just unhooks and rehooks the events (using Unadvise/Advise), and that seems to work. This is likely not the correct solution, but I have not seen it fail yet. I call that method only for Windows 10 and after a device disconnects from WMDC. Testing indicated that it should be called from the main thread not in the context of any ActiveSync/RAPI event (so don't attempt an Invoke from a Disconnect handler). Instead (at least what I did), use a periodic timer on the main thread (I already had a couple) and a bool to indicate that the call should take place -- then make the call in the main thread timer handler. In my case, that new API ended up being called within a half second of the device being disconnected, and this so far is working out well.

That single method that was added to ActiveSync.cs is...
        public void ContinueListen()
        {
            // unhook the IDccManSink
            idccMan.Unadvise(dccContext);
            dccContext = 0;

            // call advise
            idccMan.Advise(idccSink, out dccContext);
        }
Hope that helps.
Jun 5 at 12:44 PM
Thanks, cbc, that's an interesting solution, I've collected some notes in case we revisit ours.

For our apparently hardware-specific issue, we ultimately added an option to abandon monitoring device connection status and instead spawn a separate background process to connect, do its work, and then terminate. This was partly based on observation of the WMDC ui itself - for this new hardware it was also shutting itself down on every disconnect. It seems to somehow detect that a session can't be maintained for this hardware. Our mode is a little coarser than that, but the new process spawning works fine with the old hardware too. And I wouldn't be surprised if our users would prefer a consistent experience regardless of hardware model over treating some differently like the WMDC app.

We've got an increased chance that users will attempt our operations when a device is not connected, but this has otherwise been working reliably.