Fabian, thanks for your reply.
Could you please clarify what makes you think that the target UI thread differs from the original thread? Actually, we don't create (at least, explicitly) controls or other windows on secondary threads, so this hardly is the case. Also I checked all threads in debugger, and they didn't appear to be doing anything resembling the user preference change handling. Anyway, thanks for the idea with posting to another thread - it has not entered my mind before, probably I should double-check this. > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Fabian Schmied > Sent: Thursday, February 23, 2006 12:01 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Odd stack trace from a hung .NET app > > > I'm facing odd hang-ups in a mixed unmanaged/Win Form app (actually > > this is a VS 2005 with a managed add-in loaded) that I > think might be > > of interest here. The stack trace of the UI thread (captured using > > WinDbg) is posted below. Basically, what is happening here is some > > system event > > (Microsoft.Win32.SystemEvents.OnUserPreferenceChanged) being > > dispatched and handled via Control.MarshaledInvoke. However, the > > latter seems to never return. From the user perspective, the > > application appears to be unresponsive (i.e. it doesn't react to > > keyboard input), but it paints its windows, as WM_PAINT > messages seem > > to be passed via the message filter in the > CoWaitForMultipleHandles (I > > checked this by breaking in a WndProc of one of the windows). > > Unfortunately, I have no experience with VS 2005 addins, so I > can only analyze the stack trace. For me, it looks like the > UserPreferenceChanged event needs to be handled on a UI > thread, so it is posted via a synchronization context and a > control's Invoke method. > This is synchronous, i.e. Invoke waits until the posted > message has been handled, forever, as it seems. > > Invoke definitely seems to think it is dealing with a UI > thread that differs from the current thread, so if this is > true, the target UI thread seems to be blocked somehow; this > should be analyzed. If it is not true and Invoke is posting > the event to the same thread, this would seem like a bug. > > 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
