Debugger disconnection from device in .net 2005

Problem description: Error message and the headaches of dealing with M$

The path to solving: “The remote connection to the device has been lost. Verify the device connection and restart debugging.”

This is one of those random problems you have to deal with when integrating systems. The problem isn’t even on your product, but you are stuck with it because if your integrators can’t solve it, they can’t sell their products. If they don’t sell their products, you don’t get to sell yours that is included in theirs. We wanted to be a “Complete” solution, so we are stuck dealing with all these OS andd IDE issues.

Of course, the bug being from Microsoft, a solution will only be created if one of these condition is met. In order of importance

1. If you are one of these companies with billion dollar capital
2. If a few million developer complained together.
3. If 5 years has passed since the first reported instance

So, for rapid prototyping or something that needs to be done quickly, asking M$ for help is out of the question.

The setup: .net 2005 and remote debugging

We have a WinCE device running on an embedded system. MS .net 2005 is installed on the developer station with an ethernet link to the device. We have compact framework V2 installed by running conmanclientv2vs2005 on the device and a connection is established after setting the device IP on the developer station.

At first, I looked around the web for answers, but found none that fixes my problem. Noah Falk, the person in charge of the debugger for .net looked into this and haven’t released a solution yet. The detailed discussin on msdn can be read here. What I realized from this thread is that different people have different reason for the disconnection which basically breaks down to the following

1. Having a breakpoint somewhere
2. Illegal memory access violations
3. Compact framework version

The solution to them are pretty simple. By updating your compact framework to a newer version, deleting all breakpoints and partially commenting out memory access, you will be able to pin down where in the code the error occurred. It helps that this problem is purely reltaed to the debugger so even when you are disconnected, your program on the target device is still running, allowing you to print and display data.

Solved??

The problem doesn’t seem to be that simple. Yes, doing all of the above seem to alleviate the problem, but if you read the forum, most of the people who applied the solutions said that the problem came back. I had suspected that it could be a thread priority issue, but had no proof that it is so. By all benchmarks that I’ve done, CPU utilization is only around 65% with occasional spikes to the 80% range. I did however, managed to narrow it down to one API call, which led to the eventual discovery that adding a Sleep(1) solves the problem.

Because the problem only occurs while debugging, it was pushed to the back of my mind until another developer decided to un-check the seemingly innocent check box “Detect when device is disconnected” check box and all the problems went away.

The culprit? The conmanclientv2VS2005 running on the target device does not have enough priority to run so that when enough time have elapsed without the OS giving it time to service its routines, VS2005 decided that the debugger is disconnected and terminates the connection. Which could explain why deleting breakpoints for others and illegal memory accesses could also leads to the problem.

However, this might not be the final solution for others who encounter this. As I said before, there are as many reasons why a debugger could get connected as there are reasons for when your internet connection went offline.