You may want to have a look at Mike Stall's blog entries on MDbg, ICorDebug and MTA/STA like http://blogs.msdn.com/jmstall/archive/2005/09/15/icordebug_mta_sta.aspx
There's some issues with MDbg being MTA and not being able to play well with STA objects (which all UI threads should be). Now, of course MDbg is not the Visual Studio debugger (2003 or 2005); but, I imagine MDbg doesn't depart too far from how either of those two debuggers were implemented. So, it may have something to do with that. Another thing to look into would be how you are creating these non-main threads. Are they STA, or MTA? WinForms only supports being in an STA thread--I think "Unknown" means it's not STA. I'm of the opinion that Windows only supports one UI thread per process. I've seen comments on both sides of this, from credible sources. (as with many things with programming, yes you can write incorrect code that works when tested; but, you're testing in specific circumstances. Like "int * p = new int[1];delete [] p; *p=1;" in C++; it usually works, but it's bad-- but, I digress). So, I suspect you're running into a basic Windows limitation by having more than one UI thread. I'd love to have someone prove me wrong, or right, about one UI Thread per process (and "try doing this, it works" doesn't cut it, see above). May I ask: why multiple AppDomains, each with their own UI thread? Do you need to support sandboxing add-in controls or something? -- Peter Microsoft MVP, Visual Developer - Visual C# http://www.peterRitchie.com/blog/ On Tue, 18 Jul 2006 20:07:04 -0400, Michael Gold <[EMAIL PROTECTED]> wrote: >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. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
