This has never been fixed and it is fast becoming a pain in the rear to do unattended testing.
After debugging starts, I see the real time clock on the LCD stop updating. If I hit PAUSE then the code stops at one of the Thread.Sleep() lines, usually in the first task/thread that was created. Click continue and off it goes for a little while and then stops again. Repeat the PAUSE and CONTINUE and off it goes until the next pause. Time wise this is completely random.
Pretty damned annoying whatever it is and we really need a fix for this.
If I reset the device and don’t connect it to the debugger but it is running the debug code and not release code, it keeps working.
This appears to be something to do with the debug connection.
Could you post a description of this problem as a Codeplex issue? The new team at Microsoft has started to look at these issues, so it is not a waste of time anymore.
It’s not USB 2.0/3.0 related.
I use USB 2.0 when ever possible, and get the problem with ever app when adding more functionality (threads, networking, …)
Never could nail it to any specific feature I use.
I guess the scheduler stumbles when having multiple waiting threads and is in debugger mode.
This might be why hitting pause always stops on a Wait / Sleep / Join.
Countrary to what is said here, I have an app that uses a gazilion of threads, and it only freezes if I use USB3, and both VS2010 and VS2012 behave exactly the same way. On three computers.
OK, Cool. I’ve managed to create a very basic programme that hangs and found what seems to be causing the issue. The first version without the exception ran and never halted.
When I added the exception (divide by zero) it now hangs. Press pause and hit continue and off it goes for a little while again.
In my main app I have some exception handling for the GSM modem which is off during startup and I try to send data to it.
I have noticed that in my app, if there is no exceptions in the debug window, the app never pauses. Only after I see them does it start acting this way.
You can download the very simple app and try it out from here. If someone has a dev board with buttons (I was using my touch based system) then they could use this to start the exception and confirm that this is indeed the reason for the failure.
As a quick follow up to this, I re-wrote the GSM driver to do away with the throwing of exceptions and so far today the debugging has not paused once so I think that the exceptions are the issue that is causing the pausing.
Today has been a calm day with no swearing or stress and lots of coding taking place.
[quote]I think that there are many causes.
I’m not user of the GHI product but I have seen similar symptoms.
In my case, solved the problem by increasing the buffer size of debug port(USB or serial) in the porting kit.[/quote]
Is this something you could try using the sample Dave McLaughlin provided?
(in near future)
