Question

According to the WM_QUERYENDSESSION docs, “Applications should respect the user’s intentions and return TRUE.” This link summarized it as “[in XP] applications can return TRUE to indicate that they can be closed, or FALSE to indicate that they should not be closed”.

However, in my own app, it seems like the opposite is happening:

• When I return FALSE, all the running apps get terminated and the computer restarts (and when my app gets the WM_ENDSESSION message, wParam is set to 1, indicating that “the system is shutting down or restarting” (see WM_ENDSESSION docs)).

• When I return TRUE, some of the running apps get terminated, but when it gets to my app, it seems to halt the shut down process, and the subsequent WM_ENDSESSION message has wParam set to 0, as if the shut down was aborted, and my app remains open. Note also that since DefWindowProc “returns TRUE for [WM_QUERYENDSESSION]”, using that also blocks shutdown in the same manner.

If I completely remove all handling of WM_QUERYENDSESSION, then the whole shut down business goes through as normal, terminating my app and shutting down. This could indicate that there’s something just going terribly wrong in my app, since I assumed that that should result in the same behavior as using DefWindowProc. I have observed this behavior even if I pared down my handlers to ONLY be a return statement, either with TRUE or FALSE, or by passing the message and params on to DefWindowProc.

Since I don’t want to halt shut down, and was pretty much only handling it so I could log when it happens, I can just remove all handling of it and have things behave as desired. Of course, this doesn’t explain to me why this seems to be completely contradicting the docs, so I’m wondering if anyone has an ideas.

This is all going down in Windows XP, so the subsequent changes for Vista+ aren’t relevant.

Answer 1

Looks like I forgot a key bit of information about this: I was using dialog templates for my windows, so they were being handled with all the trappings of dialog boxes. As seen in the DialogProc docs, “If the dialog box procedure processes a message that requires a specific return value, the dialog box procedure should set the desired return value by calling SetWindowLong(hwndDlg, DWL_MSGRESULT, lResult) immediately before returning TRUE.”

The source of my issue could be explained with: “If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message,” i.e., returning FALSE leads to the default behavior, which is to return TRUE and not block shutdown.

It is also important to note, “Although the dialog box procedure is similar to a window procedure, it must not call the DefWindowProc function to process unwanted messages. Unwanted messages are processed internally by the dialog box window procedure.” So I was pretty much going about it all wrong.