Prev: How to debug Explorer crash on logoff
Next: PE delayed import table - need a description.
From: Brian Knittel on 25 Sep 2009 17:28
I have a question about the behavior of WM_QUERYENDSESSION on Windows XP vs.
Windows Server 2003 R2. I've read the bulletin on WM_Q/E/S changes in Vista,
and differences between XP and Server 2003 are not clarified there.

I have an application that controls hardware and has to gracefully deal with
a Windows shutdown request, whether user-invoked, or initiated by a virtual
machine manager or Windows update, or whatever the source. It has to do this
unattended. It could take anywhere from 0 to 30 minutes -- or even more --
to be able to comply with the shutdown request. There is no flexibility in
these requirements. It used to run exclusively on XP Pro. Now, a client
needs to run it on Windows Server 2003 R2.

On an XP machine, if I click Start, Turn Off Computer, an app gets
WM_QUERYENDSESSION with lParam == 0. If the app delays in responding to
WM_QUERYENDSESSION, after a time interval determined by
HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeout, UI is presented to
allow the user to terminate the program (or wait). This UI will wait
indefinitely. This is good.

If I do the same thing on Windows Server 2003 R2, after HungAppTimeout
expires, the app is summarily terminated, without WM_ENDSESSION. This is not
good.

LParam is zero in both cases - the ENDSESSION_CRITICAL flag is not being
passed either way.

What I've done as a workaround is to increase HungAppTimeout to six hours.
But I'd like to tackle the problem more directly.

So, three questions:

* Is there documentation that I've missed that explains this difference in
how app termination occurs on Server vs XP?

* Can an app determine in advance if it's at risk of being terminated w/o
futher notification?

* Most importantly, is there a way to configure Server to not simply
terminate the app (other increasing HungAppTimeout to a ridiculously large
value)?

By the way, I did try responding to WM_QUERYENDSESSION immediately, and
delaying on WM_ENDSESSION, but the same thing happens. And, this approach is
unusable in our situation. Once everyone has voted yes on
WM_QUERYENDSESSION, no logons are allowed and no processes can be started;
so the system is severely cripped until the shutdown occurs, which could be
a looooooooong time (like forever). It's just not feasible to have the
machine run in this unmanageable state, so delaying on WM_ENDSESSION is not
possible.

Thanks,
Brian


From: Remy Lebeau on 25 Sep 2009 19:57

"Brian Knittel" <briknit(a)newsgroup.nospam> wrote in message
news:%23LwpbciPKHA.1268(a)TK2MSFTNGP04.phx.gbl...

> * Is there documentation that I've missed that explains this difference
> in how app termination occurs on Server vs XP?

Not that I know of, but I did find this blog entry that touches on it a
little:

http://blogs.msdn.com/larryosterman/archive/2007/08/02/hey-my-custom-shutdown-sound-got-cut-off-or-didn-t-play-what-s-up.aspx

> * Can an app determine in advance if it's at risk of being terminated w/o
> futher notification?

No.

> * Most importantly, is there a way to configure Server to not simply
> terminate the app (other increasing HungAppTimeout to a ridiculously large
> value)?

No that I am aware of.

--
Remy Lebeau (TeamB)


From: Alexander Grigoriev on 25 Sep 2009 21:29
Make your application the only app in the login session (specify it as a
shell), so there's no possibility to issue a shutdown other than by your
program's only means.

"Brian Knittel" <briknit(a)newsgroup.nospam> wrote in message
news:%23LwpbciPKHA.1268(a)TK2MSFTNGP04.phx.gbl...
>I have a question about the behavior of WM_QUERYENDSESSION on Windows XP
>vs. Windows Server 2003 R2. I've read the bulletin on WM_Q/E/S changes in
>Vista, and differences between XP and Server 2003 are not clarified there.
>
> I have an application that controls hardware and has to gracefully deal
> with a Windows shutdown request, whether user-invoked, or initiated by a
> virtual machine manager or Windows update, or whatever the source. It has
> to do this unattended. It could take anywhere from 0 to 30 minutes -- or
> even more -- to be able to comply with the shutdown request. There is no
> flexibility in these requirements. It used to run exclusively on XP Pro.
> Now, a client needs to run it on Windows Server 2003 R2.
>
> On an XP machine, if I click Start, Turn Off Computer, an app gets
> WM_QUERYENDSESSION with lParam == 0. If the app delays in responding to
> WM_QUERYENDSESSION, after a time interval determined by
> HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeout, UI is presented to
> allow the user to terminate the program (or wait). This UI will wait
> indefinitely. This is good.
>
> If I do the same thing on Windows Server 2003 R2, after HungAppTimeout
> expires, the app is summarily terminated, without WM_ENDSESSION. This is
> not good.
>
> LParam is zero in both cases - the ENDSESSION_CRITICAL flag is not being
> passed either way.
>
> What I've done as a workaround is to increase HungAppTimeout to six hours.
> But I'd like to tackle the problem more directly.
>
> So, three questions:
>
> * Is there documentation that I've missed that explains this difference in
> how app termination occurs on Server vs XP?
>
> * Can an app determine in advance if it's at risk of being terminated w/o
> futher notification?
>
> * Most importantly, is there a way to configure Server to not simply
> terminate the app (other increasing HungAppTimeout to a ridiculously large
> value)?
>
> By the way, I did try responding to WM_QUERYENDSESSION immediately, and
> delaying on WM_ENDSESSION, but the same thing happens. And, this approach
> is unusable in our situation. Once everyone has voted yes on
> WM_QUERYENDSESSION, no logons are allowed and no processes can be started;
> so the system is severely cripped until the shutdown occurs, which could
> be a looooooooong time (like forever). It's just not feasible to have the
> machine run in this unmanageable state, so delaying on WM_ENDSESSION is
> not possible.
>
> Thanks,
> Brian
>
>


From: Brian Knittel on 26 Sep 2009 11:58
> Make your application the only app in the login session (specify it as a
> shell), so there's no possibility to issue a shutdown other than by your
> program's only means.

Unfortunately, this won't help. Shutdown can be invoked other than from this
session's Start menu: for example, from another login session, by a virtual
machine manager, remotely via WMI, and so on.

And, I don't really want to prevent shutdowns. I want to postpone shutting
down while the hardware under control is still busy, and failing that, at
least avoid having the application terminated _without notice_ during an
intended shutdown.

What I am doing now is to set a timer a couple of seconds short of
HungAppTimeout, and permit the shutdown to proceed if that much time
elapses, so I can shut shut down gracefully -- if reluctantly -- rather than
be terminated. But, it would be better to know if I was NOT going to be
terminated, so I woudn't have to bail out at all, until the hardware is
ready.

That is what I asked in my post: How can you configure Windows not to force
termination? Or failing that, how can you tell if a shutdown is going to end
in forced termination? And is there some _accurate_ documentation about
these details somewhere?







From: Brian Knittel on 26 Sep 2009 12:38
>> Is there documentation that I've missed that explains this difference in
>> how app termination occurs on Server vs XP?
> Not that I know of, but I did find this blog entry that touches on it a
> little:
>
> http://blogs.msdn.com/larryosterman/archive/2007/08/02/hey-my-custom-shutdown-sound-got-cut-off-or-didn-t-play-what-s-up.aspx

Is there anyone at Microsoft with responsiblity for this area who does know?
I've not been able to find a discussion of the shutdown semantics in Server.

Microsoft's writeup comparing shutdown in Vista to XP
(http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx) mentions a
flag named ENDSESSION_FORCEFULSHUTDOWN passed in WM_QUERYENDSESSION, but
there is no flag with this name defined in the Windoww SDK.

(And this is just one of the finer details. There are a whole raft of web
pages and blogs out there covering shutdown messages that have even the
basic details wrong. Even the aforementioned Microsoft writeup
http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx gets it wrong
in two places, including this incorrect statement: "Shutdown then continues,
as Windows sends WM_QUERYENDSESSION and WM_ENDSESSION to the remaining
running applications in turn.")

>> * Can an app determine in advance if it's at risk of being terminated w/o
>> futher notification?
> No.

The "forced shutdown" mode is known by the process that is supervising
shutdown. It can't be queried by applications? There is no API access to
this information?

Are you absolutely certain? Is there anyone at Microsoft with responsibility
in this area who knows this for sure?

>> * Most importantly, is there a way to configure Server to not simply
>> terminate the app (other increasing HungAppTimeout to a ridiculously
>> large value)?

MS, is there anyone there with responsibility for this part of Windows
Server who knows the answer to this?

Thanks
Brian


 |  Next  |  Last
Pages: 1 2 3
Prev: How to debug Explorer crash on logoff
Next: PE delayed import table - need a description.