WM_QUERYENDSESSION

[Ratch]

To the Ineffable All,

     I don't receive the WM_QUERYENDSESSION message for my single thread window program when I terminate it.  I am running with XP O/S.  All the documentation seems to indicate that every window should get this message before shutdown.  Any helpful insights or ideas?  Ratch 

[zooba]

IIRC, WM_QUERYENDSESSION is sent before the computer is going to be shut down (ie. end Windows session). Try running your program and shutting down your computer.

Cheers,

Zooba :U

[dsouza123]

I asked this in a thread but it got lost with the forum hack.
There were good replies and ended with a workable solution.

The end result that worked, was to not process WM_QUERYENDSESSION,
it is handled by the default message handler, which says the program is OK
with shutdown/logoff, and wont try to stop it.

WM_ENDSESSION does get handled though, any finishing code is done then,
ie saving files, settings etc.

[dsouza123]

  The two messages are OS generated when shutdown/restart/logout has been
initiated the first WM_QUERYENDSESSION is sent to each process, giving each
process a chance to block the shutdown. It was very complicated to respond to,
and since the default message handler deals with it saying it is OK by default,
that is how I dealt with it.

  If no process blocks it, shutdown procedes and the WM_ENDSESSION message
is sent to the processes, this is the important message to handle, and do final
saving of items.

  If you are doing a regular exit (manual/program initiated) other messages are
generated instead such as WM_CLOSE and WM_DESTROY.

[Ratch]

zooba,

IIRC, WM_QUERYENDSESSION is sent before the computer is going to be shut down (ie. end Windows session). Try running your program and shutting down your computer.

     Thanks, that is exactly what happens.  The documentation also says that the ExitWindows API will also post that message.  I have found a simple termination of the application will not post that message.

dsouza123,

The end result that worked, was to not process WM_QUERYENDSESSION,
it is handled by the default message handler, which says the program is OK
with shutdown/logoff, and wont try to stop it.

     If the program doesn't process that message, the user does not any control over whether the O/S will shut down or not.

WM_ENDSESSION does get handled though, any finishing code is done then,
ie saving files, settings etc.

     When a program receives WM_ENDSESSION, it has no more control over whether the O/S will shut down or not.  WM_ENDSESSION is a informational message, not an invitation to make a selection.

     Thanks again to both of you.  I now think I have my head screwed on right in regard to WM_QUERYENDSESSION.  It is a message about session termination, not application termination.  Ratch

[Ian_B]

There was a useful discussion about this here: http://www.masm32.com/board/index.php?topic=3937.0

[dsouza123]

Does anyone know how to handle WM_QUERYENDSESSION so it halts/delays shutdown ?
Versus not handling it, letting the default message handler reply OK for shutdown.

If it is handled and the reply sent is Not OK, will windows retry sending WM_QUERYENDSESSION ?
With the realization windows can be configured in different ways, what is the default scenario
if OS termination settings have not been changed ?

Ratch

  It is true how I dealt with it didn't give the option of blocking shutdown/restart/logout but
I was concerned with not losing work done and settings changed with a OS initiated exit.

dsouza123

[Ian_B]

The WM_QUERYENDSESSION message is sent when the user chooses to end the session or when an application calls the ExitWindows function. If any application returns zero, the session is not ended. The system stops sending WM_QUERYENDSESSION messages as soon as one application returns zero.

According to the discussion in the other thread I linked, all you can do is ask to delay and start shutting your app down immediately and as gracefully as possible at that point, in case you aren't going to get the option. Once you have the informational ENDSESSION message after the QUERYENDSESSION, your app can be terminated at any time so you should be well on the way to finished at that point. The danger is going to depend on how much information you have to save to disk from memory to save state for the next startup, if your app is holding a lot of stuff in memory.

As the blog commentary linked in the other thread shows, however, so many apps ask for delay often without any real need that yours likely won't be the only one. This is why new OS policies in newer versions of Windows are removing the ability of apps to affect the shutdown process. Assume that you won't get much notice of a shutdown and that you may not be able to stop it, and you'll have an app that should work in all cases. If the user is going to terminate your app or his session prematurely despite it damaging data, that's their lookout, not yours. You just have to manage the state-saving in a way that may minimise the damage, ie. not having too much to save/process at the QUERYENDSESSION message. Starting a new thread to handle state-saving immediately on QUERYENDSESSION may be the way to get a head-start, while trying to finish any current processing.

Ian_B

[Casper]

Casper says...

I do not think you are correct.  This is what I read...

The WM_QUERYENDSESSION message is sent when the user chooses to end the Windows session or when an application calls the ExitWindows function. If any application returns zero, the Windows session is not ended. Windows stops sending WM_QUERYENDSESSION messages as soon as one application returns zero.

So you can stop the end session process.

[tenkey]

Check out ExitWindowsEx at MSDN.

Basically, under NT and Win2k, you can force termination with ExitWindowsEx. In that case, no ENDSESSION messages will be sent.
Under XP, the ENDSESSION messages will always be sent, but you can force termination after a timeout (after the ENDSESSION messages are sent).

[Ian_B]

Casper says...

I do not think you are correct.  This is what I read... [SNIP]

So you can stop the end session process.

Apart from the situation TenKey has mentioned, this is generally true, but use of forced exits and the change of policy threatened for newer versions of Windows mean you cannot be sure. If you want portable code that will behave well in all versions of Windows it's better to be safe than sorry and plan to have as little left to do as possible when you get your ENDSESSION notification.

Ian_B