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

[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.EnableRaisin gEvents 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

[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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:OU******** *******@TK2MSFT NGP10.phx.gbl.. .

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.EnableRaisin gEvents 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

[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

"Stephen Martin" <sm*****@remove this.emsoft.and this.ca> wrote in message
news:%2******** *********@TK2MS FTNGP12.phx.gbl ...

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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:OU******** *******@TK2MSFT NGP10.phx.gbl.. .

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.EnableRaisin gEvents 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

[Stephen Martin]

I don't think you can tell what the shutdown reason is. The underlying
WM_QUERYENDSESS ION 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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:Oo******** ******@TK2MSFTN GP11.phx.gbl...

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

"Stephen Martin" <sm*****@remove this.emsoft.and this.ca> wrote in message
news:%2******** *********@TK2MS FTNGP12.phx.gbl ...

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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:OU******** *******@TK2MSFT NGP10.phx.gbl.. .

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.EnableRaisin gEvents 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

[AlexS]

From what I know, actual ForceReboot or something like that key is set into
registry in Windows. However, MS is not very specific which version puts the
key where. One of KBs points to CurrentControlS et/Control/Windows but I
never seen this key there.
You might try this one
http://msdn.microsoft.com/library/de...oot_action.asp
I have slight suspicion that restart is implemented using this feature.
HTH
Alex

"Stephen Martin" <sm*****@remove this.emsoft.and this.ca> wrote in message
news:u9******** ******@TK2MSFTN GP11.phx.gbl...

I don't think you can tell what the shutdown reason is. The underlying
WM_QUERYENDSESS ION 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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:Oo******** ******@TK2MSFTN GP11.phx.gbl...

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

"Stephen Martin" <sm*****@remove this.emsoft.and this.ca> wrote in message
news:%2******** *********@TK2MS FTNGP12.phx.gbl ...

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.
"Jerry Camel" <rl*****@msn.co m> wrote in message
news:OU******** *******@TK2MSFT NGP10.phx.gbl.. .
> 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.EnableRaisin gEvents 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
>
>