Considerations on KB 813579

I recently encountered this bug, Cannot Deploy Smart Device Application After You Remove and Reinstall ActiveSync, with the following error message, Error: Cannot establish a connection. Be sure the device is physically connected to the development computer

To fully understand this bug, one must first understand that there are a set of requirements needed to debug a device, and that those requirements may be fulfilled by installing Visual Studio 2003 and ActiveSync in a particular order. Add to that a registry modification or two. When the requirements are met, a developer follows a few more configuration steps (I myself [must] use SDeviceAuthUtil) to allow Visual Studio to communicate with the device, then hits the debug button and off they go debugging their application. However, one day, this connectivity may stop working for no particular reason. At that point, KB 813579 comes into play because any attempt to debug (and sometimes deploy, as was my case) is met with failure. ActiveSync continues to work, the device continues to have no problems with a network connection, and you can even ping the device from the development workstation. But Visual Studio 2003 has had enough and refuses to play anymore.

And, if one were to follow the instructions in that article to recover from the bug, then that person will spend the next several hours or more uninstalling and reinstalling, only to find out that the fix may or may not work.

For a long time, I knee-jerk reaction to development problems has been to search Deja News (now Google Groups) for others who have had that problem primarily because I have found the KB articles to either be too hands-off in providing a solution (culminating in a "Declaration of Re-installation") or too modularized (eg: circa twenty KB articles all describing the same problem, each with a different solution). I have neither the time nor the inclination to routinely re-install software that may or may not fix a specific problem, and have found better success by locating people who have had the same problem.

In this case, I spent several late-night hours trying to find a solution, and returned to the KB Article because at some point one must admit that spending ten hours running in a circle is not a good use of time if spending two hours re-installing might work. So, I tried the Visual Studio 2003 re-install. No good.

Back to the groups. In one group, I found a link to a forum topic on OpenNETCF.org which included a number of helpful suggestions. From the suggestions offered in the topic, I went back and created my own winning combination.

Now, I want to instruct the astute reader that my particular experience with this bug may not apply to them because after seeing the number of people with this problem, and no specific solution, I don't want to get anyone's hopes up. First, here is a brief list of things I tried that didn't work: a hard reset, re-installed Visual Studio 2003, un-installed and re-installed the Smart Device components of Visual Studio 2003, uninstalled and re-installed ActiveSync (which turned out to be 3.5), applied the ProxyPort.reg file, applied a copy of ProxyPort.reg from another machine, applied a copy of ProxyPort.reg obtained from the previously cited OpenNETCF.org forum topic, and uninstalled and re-installed ActiveSync 3.7 (which didn't fix the problem .. yet).

Then, I re-read the forum topic, and added my own two bits two it. This, folks, after all of the previous efforts (so I don't know if any of those attempts helped at all, but I doubt it), was the winning combination: un-installed ActiveSynce 3.7, applied ProxyPorts.reg from the Visual Studio CE Utilities add-on, re-installed ActiveSync 3.7, verified registry entries were correct, restarted machine for posterity, started Visual Studio 2003, started the SDAuthUtilDevice.exe on the device, ran SDAuthUtil from Visual Studio (I had tried this much earlier in my attempts, but it had failed), and this time it connected.

While I am not certain which specific steps are necessary - is it just the registry entries, or a combination of the registry entries and then installing ActiveSync after applying them, or something else - I do know that early on I had checked the registry and found that my entries for ProxyPorts had been wiped clean. Also, the order of installation was crucial because I had tried various versions of these steps, such as installing the ProxyPorts after installing ActiveSync and then trying to run SDAuthUtilDevice, but that wouldn't work.