I observed the same behaviour with VS2003. Although I don't know if you've hit the same problem, in our case it, the problem turned out to be the interaction between 'Allow Property evaluation in variables window' (in Options/Debug/General) being turned on, and having a 'watch' on a property of some Control. I guess that forces the debugger to do a FuncEval on the property, from a different thread, which ultimately results in a windows message being sent cross-thread (we had watch on a Control.Text property which resulted in WM_GETTEXT) and this sometimes (because of the window manager's design that only the thread that created the window can process its messages) causes a deadlock -- which eventually forces the debugger to abort the thread the is doing FuncEval on the property - and hence the ThreadAbortException.
Also, please mind, that having a watch is not the only way to hit this problem, it can also came from the tooltips that the debugger displays sometimes. As somebody already mentioned this is all explained (very well) in Mike Stall's blog -- especially the entries about FuncEval In short, try to turn off 'Property evaluation' and see if this helps. Danny ----- Original Message ----- From: "Michael Gold" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 19, 2006 3:07 AM Subject: [ADVANCED-DOTNET] VS2003 Debugging Issues with Multiple UI Threads
Hello, My team has developed an application that uses Multiple AppDomains and Multiple UI threads to house somewhat related components (or sub-applications) within a common UI "shell" allowing these components to communicate in a loosely coupled fashion and all that other good stuff (its somewhat CAB like, but we think better). It works great, except we are running into a problem with the vs2003 debugger where we set a break point in one of the sub-applications and then close the sub-app (which causes an Application.Exit in its AppDomain) and then re-open the sub-app (which creates a new AppDomain and UI Thread). Soon after doing that, when the break point is hit, the debugger will freeze for 10 seconds and then throw a first chance ThreadStopException which will cause the sub-app to crash. The problem only seems to happen in the debugger and under very limited testing in vs2005, we don't see the problem (unfortunately we are still stuck in a 1.1 world for now). Has anyone tried anything similar or seen this behavior from the debugger? I googled for ThreadStopException and found some chatter about the Watch window causing this, but we still get this problem even if we hide all the watch/locals/etc windows. Thanks in advance for any suggestions. Mike =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
