Prev: How to debug Explorer crash on logoff
Next: PE delayed import table - need a description.
From: Alexander Grigoriev on 27 Sep 2009 09:58

But if the user can't invoke shutdown by any other means (short of
unplugging the power) then the problem is solved, I guess.

"Remy Lebeau" <no.spam(a)no.spam.com> wrote in message
news:eyEgwtzPKHA.1232(a)TK2MSFTNGP05.phx.gbl...
>
> "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message
> news:e$KjNjkPKHA.1268(a)TK2MSFTNGP04.phx.gbl...
>
>> 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.
>
> The OS runs the shell as a user-mode application, and thus is subject to
> the same shutdown rules as other user-mode applications. MSDN says as
> much. The actual shutdown is managed at a lower level.
>
> --
> Remy Lebeau (TeamB)
>


From: Brian Knittel on 28 Sep 2009 02:04
>> 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.
>
> Are you using an up-to-date Platform SDK?

Yes, v7.0. It's called the Windows SDK now. The .NET Platform SDK has been
merged into it.

I'm guessing that the article meant to call the flag ENDSESSION_CRITICAL,
which is new and which is defined in the SDK. Maybe the flag got renamed
during the beta process, and the article wasn't updated.

(The description of ENDSESSION_CRITICAL in
http://msdn.microsoft.com/en-us/library/aa376889(VS.85).aspx is pretty
vague.)

>> (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.
>
> Such as? Shutdown behavior does differ from version to version.

One aspect of shutdown that does not vary from version to version, and which
is widely written about incorrectly, is the shutdown polling process. The
heresy is stating that Windows sends a top-level window WM_QUERYENDSESSION,
waits for a response, sends it WM_ENDSESSION with the go/no go decision, and
then proceeds to the next top level window. This is incorrect. Yet it's
common on non-Microsoft discussions of the messages, and even appears in a
few Microsoft web pages.

If this were true, then some applications would be sent WM_ENDSESSION with
the results of the vote before all of the applications had voted. (This may
be how elections work in some places, but not in Redmond, WA).

What DOES happen in every version of Windows is that Windows sends a
top-level window WM_QUERYENDSESSION, waits for a response, and if the
reponse is TRUE, sends WM_QUERYENDSESSION to the next top level window, then
the next, and so on. Only when the vote is over (that is, when either
everyone has responded TRUE, or, an app has vetoed shutdown by responding
FALSE), does the result get communicated back to anyone with WM_ENDSESSION.
If shutdown it to proceed, everyone gets notified via WM_ENDSESSION with
wParam == TRUE. If shutdown is averted, presumably only apps that had
previously been polled with WM_QUERYENDSESSION will get notified via
WM_ENDSESSION with wParam == FALSE; but I'm not sure about that, never
tested it. Maybe everyone gets WM_ENDSESSION in this case too.

What varies from version to version is how Windows deals with a top level
window that fails to respond to WM_QUERYENDSESSION or WM_ENDSESSION
promptly, as measured by the HungAppTimeout value. Windows has to decide
whether or not to hold up shutdown waiting for an application that is
waiting for user input, or, for all anyone knows, might be brain dead. (Or,
like mine, is waiting for something that is taking a long time to complete).

The writeup I mentioned discusses the details of how Windows makes the
decision for XP and Vista, but not Server. My question is about Server makes
the decision. I haven't seen it described anywhere, but I'm hoping that
someone here has.

>> 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.")
>
> That is correct behavior in XP, which the paragraph that statement appears
> in is describing. Besides, you are taking that statement out of context
> anyway. It is saying that shutdown continues after an app has replied
> TRUE to WM_QUERYENDSESSION and has recieved WM_ENDSESSION.

Read it again! It states that Windows polls an app WM_QUERYENDSESSION, sends
it result with WM_E/S, and then "sends WM_QUERYENDSESSION and WM_ENDSESSION
to the remaining running applications in turn." No!

Another error is in this statement: "the application that cancelled shutdown
is sent WM_ENDSESSION with wParam == FALSE". Wellllll, technically, yes, it
is, but this is misleading. It's not just the one app canceling shutdown
that gets sent WM_ENDSESSION. EVERY app that was previously polled with
WM_QUERYENDSESSION is sent WM_ENDSESSION with wParam == FALSE. (And maybe
every window, period).

And, then, there's the use of "application" where it should say "top level
window" But that's maybe quibbling.

My point here is that a Microsoft web page discussing the fine points of
shutdown polling should not get the gross details wrong.

>> 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?
>
> Nope, none.

That's unfortunate. But, it makes sense that it's so, otherwise they
wouldn't have needed to define a new flag (ENDSESSION_CRITICAL?
ENDSESSION_FORCEFULSHUTDOWN?), which only is set on Vista and later -- not
Server 2003 R2 which is what I am inquiring about.

I will just assume that cancellation is going to occur, and unblock a few
seconds before HungAppTimeout. I'll leave HungAppTimeout set to several
hours. By then, someone will definitely have noticed that the application is
refusing all requests for new work and can do some manual intervention to
let the shutdown proceed. Ugh.


From: Brian Knittel on 28 Sep 2009 02:07
>> MS, is there anyone there with responsibility for this part of Windows
>> Server who knows the answer to this?

> Yes, but they don't read this newsgroup. They are the Product support.
> If you have MSDN subscription, it usually comes with a certain number
> of prepaid support incidents that you can use to solve such issues.

This is one of the managed newsgroups. See e.g.
http://msdn.microsoft.com/en-us/subscriptions/aa974230.aspx



From: Brian Knittel on 28 Sep 2009 02:16
> But if the user can't invoke shutdown by any other means (short of
> unplugging the power) then the problem is solved, I guess.

There are several ways shutdown can be invoked besides clicking the Start
button, so eliminating the Start button won't help.

And -- the point is not to prevent shutdowns. It's that I need -- when
necessary -- to be able to to delay shutdown until I can do it without
losing the work that the hardware is busy with.

If termination is going to happen, I'd rather shut down gracefully and lose
the work in progress than be terminated without telling the hardware
goodbye. I just don't want to do that unnecessarily. Hence the desire to
know if termination is on the agenda.







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