It seems that I was wrong - that background thread seems to do Control.Invoke periodically showing the progress of a background operation. So now I'm almost sure that the problem relates somehow to this thread. A plausible hypothesis is that a control get created on the background thread, and the primary UI thread tries to marshal user preference change handler to the background thread, but that's not possible as the background thread waits on a wait handle and doesn't process its message queue. Although this would be really strange, as all UI-related calls are done via Control.Invoke from the background thread, and it's unclear how a control can be created on it. Checking all points where controls are created is a daunting task as the add-in is really large and uses many 3rd party and custom controls.
Unfortunately, the problem has suddenly stopped to reproduce (on the same versions of binaries), so I guess I will have to return to it next time it manifests itself. Thanks for your ideas. > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Fabian Schmied > Sent: Friday, February 24, 2006 2:10 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Odd stack trace from a hung .NET app > > > The problem is almost 100% reproducible, and during the > last debugging > > session I noticed only two managed threads: > > the first one is the primary thread with the stack trace I > posted in > > the original message, and the second one is a background > worker thread > > which performs jobs in the background. > > Okay, that's really strange. If you are correct and there is > only one UI thread, then Control.MarshaledInvoke should not > go into the branch with WaitForWaitHandle. > > AFAICS > > ((SafeNativeMethods.GetWindowThreadProcessId(new > HandleRef(this, this.Handle), out num1) == > SafeNativeMethods.GetCurrentThreadId()) && synchronous > > should yield true in this situation and > InvokeMarshaledCallbacks should be invoked. Can you check > this somehow, e.g. by putting breakpoints on these methods? > > If it does not yield true, this means the control was indeed > created on a different thread (check all control creation > points for that). If it does yield true, as it should, > InvokeMarshaledCallbacks seems to do something strange (i.e. > not complete the call). > > Fabian > > =================================== > This list is hosted by DevelopMentorR 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
