Threading Issues (If you can answer this, I'll kiss you.)

J

Jerry Camel

Any insight here is greatly appreciated... (Eveything is in VB .NET)

Here's the baisc app flow:
-------------------------------------
Launch wrapper.exe:
wrapper.exe registers for the SessionEnding system event
wrapper.exe stores a pointer to its thread in MainThread
wrapper.exe declares, withevents, a process variable: np
wrapper.exe does some basic maintenance
wrapper.exe populates np with process info and sets
fp.EnableRaisingEvents to True
wrapper.exe launches fp
wrapper.exe suspends its thread <- Waiting for fp exit
wrapper.exe does some basic maintenance
Exit wrapper.exe

SessionEnding Handler: (User is logging off or shutting down without
exiting fp)
force fp to exit
End Handler

fp Exit Handler: (fp has exited either via user interaction or the
SessionEnding Handler)
resume MainThread
End Handler
------------------------------------

If the user exits fp then everythign works just fine. If the user tries to
shutdown or logoff while fp is still running, then my SessionEnding handler
never gets called. The message just waits in the queue and fp is never
forced to exit and the user gets a dialog box claiming that some .NET
process isn't ending. (This is the typical dialog seen when a process
doesn't play nice at shutdown.) While that dialog is on the screen, if the
user then shuts down fp, my code will continue to run.

So, here's the basic question. Why does the ExitHandler run while the
MainThread is suspended, but the SessionEnding Handler does not? (If you
need more info to provide some advice, please let me know...)

Thanks.

Jerry
 
S

Stephen Martin

When you register for a SystemEvent a window is created to receive the OS
broadcast messages. In your case the window is created on your main thread
but that thread is suspended so when the session ending broadcast message is
sent it is not read from the message queue and your SessionEnding handler is
never called.

On the other hand when you register for the process exit event the system
simply registers a wait on the process handle with the ThreadPool. When the
process exits a threadpool thread then calls your event handler. So the Exit
handler is not blocked by suspending your thread since it is called on a
different thread.

I assume in your case that your app is a console app and you do not want to
use a form on your main thread to provide a message pump for the broadcast
window. If that is the case, I think adding a MTAThread attribute to your
Main function in wrapper.exe might do the trick. The framework assumes that
any STA thread has a UI and so creates the broadcast window on that thread
but if the thread is MTA then no UI is assumed and a thread is created
specifically to handle the broadcast messages. The VB compiler, by default,
makes your Main thread STA unless you add the MTAThread attribute.
 
J

Jerry Camel

That helps explain the what's happening. I had worked around it by spawning
a new thread that does nothing but register for the system event. Now I
understand why that works. I'll look into the MTAThread attribute as a
solution as well...

Here's the kiss I promised... >*< SMACK >*<

I promise not to kiss you again if you can answer this...

The session ending event will tell me if the user is logging off or shutting
down, but does not differentiate between a user shutting down and a user
restarting the box? How can I tell what action the user has tried to
initiate? Thanks for you insight.

Jerry
 
S

Stephen Martin

I don't think you can tell what the shutdown reason is. The underlying
WM_QUERYENDSESSION message only tells you Shutdown or Logoff. There may be
something in WMI that would give you more information but I'm not overly
familiar with WMI so I can't give you any guidance there.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top