Debugging Threads In VS2005? Woe To Thee!

Ok folks, this is mostly a post for my own personal use. Basically, so the next time I run into the problem, I'll remember that I wrote this post. :)

While the title is misleading -- debugging in VS2005, especially debugging when debugging multithreaded apps. I've just ran into a problem though.

See, I'd set a breakpoint inside some code that's executing on another thread. When the breakpoint hits, VS2005 just sits there for about 10 seconds. It's like it's dead. Then, after it comes-to, if I try to step-through, or step-into any code after the breakpoint weird things happen. Like, it doesn't step-forward into the code. And while the IDE indicates the app is still in a 'paused' state, it certainly doesn't have any instruction pointer, nor does the "Threads" debugger panel indicate that your extra thread even exists anymore! Hitting "F5" and letting it go about it's business doesn't help either -- the app is now in some sort of voodoo-ized state.

The only solution is to stop the app and restart it.

This still doesn't help the fact that I can't debug any code running on a non-main/UI thread!


What to do?


Off to the MSDN forums for me!

Here's a post that helped me: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=285644&SiteID=1
That post links to this post:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=147707&SiteID=1
And that post links to this blog:
http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx

Basically, what's happening is the debugger is trying to peek at all the local variables in order to 'help you' debug. Unfortunately, access the GUI objects created on the main/UI thread from another thread is bad juju, and the debugger hangs when it hits a breakpoint while trying to probe values from objects owned by the UI thread. Why it screws everything else up, I don't know.

BUT, I've come up with a solution not listed in the above links -- disable/close/don't-look-at the "Locals" debugging panel. If that panel isn't visible, the debugger won't waste time poking-n-prodding all the objects found in the current scope, and you'll avoid the problem entirely. :)