Trapping Windows Logoff/Shutdown

[V Coder]

What WM_ message does Windows XP send to applications when it is about to logoff or shutdown please?

[ramguru]

WM_QUERYENDSESSION and WM_ENDSESSION I guess.

[Tedd]

WM_QUERYENDSESSION asks each process whether it's safe to end the current session.
WM_ENDSESSION indicates the session WILL now end.


If any process returns false to queryendsession, then the session isn't ended (and so endsession isn't sent.)

[Ian_B]

Question. MSDN says:

If your application receives a shutdown notification while it is in the middle of an operation that should not be aborted, such as burning media or making a backup, it should display a dialog box. Warn the user what might happen if the operation is interrupted and enable the user to choose whether to cancel or continue the shutdown. If the user would like to cancel the shutdown, the application should return FALSE for this message.

Suppose that your application is in the middle of some processing, that may not take as long as a CD burn. If it waits for that to finish before returning an "OK, close me" value, then surely the OS will hang on until the function returns... so you could instead put up a dialog saying "MyApp finishing processing" or something instead. It won't get forcibly unloaded until the function returns TRUE, surely?

EDIT: another triumph for MSDN organisation...  :wink   It appears that you should instead wait until you've been informed that the system is definitely shutting down with a WM_ENDSESSION message, and then hold everything up!  :bdg

The WM_ENDSESSION message informs the application whether the session is ending... If the wParam parameter is TRUE, the session can end any time after all applications have returned from processing this message. Therefore, an application should perform all tasks required for termination before returning from this message.

IanB

[zooba]

Isn't that the point where the system waits 5 seconds or so and then prompts the user to end the application?

[Timbo]

Windows 2000 and XP workstations can be configured to not wait for process termination (it's violent and immediate).  It's not safe to assume the OS will wait for you.  Since it is no longer in your hands at this point, you can do the best thing by flushing your IO buffers at WM_ENDSESSION at the lastest; preferably at WM_QUERYENDSESSION.

API Hooking will probably allow you to skirt around this if you insist.

Regards,

Tim

[Ian_B]

Windows 2000 and XP workstations can be configured to not wait for process termination (it's violent and immediate).  It's not safe to assume the OS will wait for you.  Since it is no longer in your hands at this point, you can do the best thing by flushing your IO buffers at WM_ENDSESSION at the lastest; preferably at WM_QUERYENDSESSION.

Not sure I like the sound of this. I'm writing a multi-threaded app, and it's all very well my message loop getting a QUITSESSION message, but it then has to wait for the threads to finish processing potentially large amounts of disk IO and then save state before exit, it's not going to be easy to just stop processing dead and flush buffers...  :'(

IanB

[Tedd]

The session message are sent async, I would assume. So it doesn't halt pending your reply, but I assume there is some maximum reply timeout -- but this is normal for any message since your app may halt (a la "the program has stopped responding...")
I would return true for queryendsession, and possibly take steps to prepare for closing (it may not actually be necessary, but you can expect it will do in most cases.) Shortly after, you will receive endsession, at which point you'll be flushing and waiting, so it's probably a good idea to display some kind of "Please wait the application finishes" to the user (just in case windows asssumes it's not responding) and then finally return from endsession.
You can't control the user, and if they decide to kill your app forcefully, and that causes a mess, that's their problem.

[Ian_B]

You're right. Currently I have a master global flag set by the main message handling loop that the processing thread checks periodically to see if there's been a close request, before it starts on the next file in sequence, else it closes shop and posts a message back to the main app, while updating another global flag to say it's not active any more that the message loop can check. I guess I have to check more frequently, and think how I can make the state-saving more incremental rather than dealing with it as a single large task before exit. Hmmmm...  :eek

IanB

[zooba]

If your program is performing a long task you'll want to keep the state stored somewhere involatile anyway in case of power failure.

Needless to say, if the power goes out you're not going to get any window messages :wink :U

[vitsoft]

Raymond Chen has an interresting thread on his The Old New Thing blog concerning shutdown/suspend philosophy.