Mike Burns e-mailed me a follow-up to an old thread, where Dmitry
Shaporenkov described having problems with an odd deadlock/hang with a
.NET windows forms app (actually a VS 2005 add-in). The stack trace
showed that the UI thread blocked in reaction to the
Microsoft.Win32.SystemEvents.OnUserPreferenceChanged event.
Mike seems to have found the reason for that problem, so I'm
forwarding his mail to this list, see below.
Fabian
---------- Forwarded message ----------
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sep 28, 2006 5:06 PM
Subject: Re: [ADVANCED-DOTNET] Odd stack trace from a hung .NET app
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
I stumbled across this post while investigating mysterious lockups in
our application. I found it in an archive and was unable to post
there.
Hopefully these e-mails are still current.
We finally figured out what was causing our problems (and I bet it's
the same problem you are having).
Certain controls in .NET 2.0 register for the
SystemEvent.UserPreferenceChanged event.
Progressbar, RichTextBox, any top level dialog, and a few others.
When the OS throws this event (either a system color changes, system
resolution changes, or any other number of changes), the event is
thrown to each of the controls that registered.
Unlike other events in the system, a synchronization context is kept
with the delegate, so the delegate can be Invoked on a different
thread.
If you create a control on a thread without a message pump attached
(pretty much any background thread), and a System Event is generated,
your application will hang trying to invoke the Event onto your
background thread.
If you are running in the debugger, you will not see the application
hang. When running in the debugger, the debugger attaches to the
vshost process. When using a vshost process, SystemEvents are not
handled by the gui thread. They are handled by the ".NET
EventQueueThread", a thread that is only created when using the
debugger. If an event is thrown, that thread is blocked, but your
application will continue to run. (doing a very effective job of
hiding the problem)
Anyway, there is a new lesson here.
Not only are you not allowed to access a control from a thread that
didn't create it, you aren't allowed to create a control on any thread
that doesn't have a message pump attached. If you do, and the control
registers for SystemEvents, and a SystemEvent is thrown, your gui will
hang.
Burns
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
