Debugging Non-UI threads in Visual Studio?

November 17, 2005 2:53 AM

Why can't I debug non-UI threads in Visual Studio 2005?

I only started using VS 2005 in the last release candidate, so I'm not sure if this occurred in other builds as well, but it is definitely in the release candidate and the final release. It seems that when I create non-UI threads in my Windows application (simple Thread objects using new Threadstart), if I set breakpoints in those threads and try to step over, the debugger will kill the thread with a ThreadAbort exception. If I don't set breakpoints, it works just fine. Does anyone have any idea? I can provide a simple sample if necessary... and I noticed that it doesn't happen in console applications.

posted by antifuse to Computers & Internet (2 answers total)

I don't know the real, actual reason, but if you think about it, it makes sense. Using breakpoints to do step-by-step debugging is a sequential process where one line of code can't be executed before the preceeding one. When you start a new thread you're starting an asynchronous process where the OS is welcome to run code from either thread in whatever order it wants.
This results in a situation where the debugger doesn't have any context for how to handle the code in the additional thread.
My experience has been that often a breakpoint in a new thread will be reached, but then I can't move forward because the original thread has continued on and the debugger is no longer where it thinks it should be.

If I really need to debug that way, I tend to just temporarily disable the multi-threaded aspect of that code.
posted by frufry at 6:40 AM on November 17, 2005

Response by poster: Hrmm, well Visual Studio 2003 had no problem with this at all, so this is definitely a step backwards in the latest VS. An asynchronous thread running apart from the main thread still has to run its code in order, after all.
posted by antifuse at 7:27 AM on November 17, 2005