WM_QUERYENDSESSION Windows session end causes
Viktor Kushnir
session end message sent:
- system shutdown request;
- system reboot;
- system power off;
- reboot in MS DOS (on Win9X)?
It seems, WM_QUERYENDSESSION has only one parameter, which allows to
determine the case of the user log-off. Any way to get more information?
Thanks,
Viktor
Kirk Ferdmann
news:eVF5MMjn...@TK2MSFTNGP11.phx.gbl...
> Does anybody know how to determine what caused WM_QUERYENDSESSION Windows
> session end message sent:
> - system shutdown request;
> - system reboot;
> - system power off;
> - reboot in MS DOS (on Win9X)?
AFAIK there is no documented method to distinguish between those. But I'm
curious why do you need it?
-Kirk
Viktor Kushnir
> AFAIK there is no documented method to distinguish between those. But I'm
curious why do you need it?
>
> -Kirk
Kirk,
I am trying to suspend shutdown to be able to perform fairly havy disk
operations at clean stages of my program, and to resume an appropriate type
of shutdown after I am done. Without this logic Windows displays "Do you
want to terminate?" type of dialogs for my application.
Viktor
Alexander Grigoriev
if the session is forcibly terminated. The best you can have is to commit
all the current state to the disk at WM_ENDSESSION, set a value in
HKCU\Software\Microsoft\Windows\CurentVersion\RunOnce to restart your
program at the next startup, an on restart do whatever finishing actions you
need.
"Viktor Kushnir" <vkus...@vkushnir.com> wrote in message
news:OW8NmQun...@TK2MSFTNGP12.phx.gbl...
Viktor Kushnir
> I'm afraid you won't be able to do it sometimes. QUERYENDSESSION is not
sent
> if the session is forcibly terminated. The best you can have is to commit
> all the current state to the disk at WM_ENDSESSION, set a value in
> HKCU\Software\Microsoft\Windows\CurentVersion\RunOnce to restart your
> program at the next startup, an on restart do whatever finishing actions
you
> need.
Thanks Alexander!
It's a feasible solution. But to be honest, the forceful termination isn't
my biggest concern. I can ignore it at the moment. I am a little bit
surprise to notice Microsoft provides a number of programmatic ways to
request various types of shutdown (like ExitWindows, InitiateSystemShutdown
and their Ex-versions) and no way to determine what type of shutdown was
requested originally when they give you a chance to reject it.
Viktor
Kirk Ferdmann
> It's a feasible solution. But to be honest, the forceful termination isn't
> my biggest concern. I can ignore it at the moment. I am a little bit
> surprise to notice Microsoft provides a number of programmatic ways to
> request various types of shutdown (like ExitWindows,
InitiateSystemShutdown
> and their Ex-versions) and no way to determine what type of shutdown was
> requested originally when they give you a chance to reject it.
There are many applications out there that just pause the inside
WM_ENDSESSION handler to finish mucking up with their stuff. Some of them
even nicely display a progress bar. IMHO it's a hack.
See the real problem is the ability to pause the shutdown not the ability to
distinguish between the reasons for it. Stopping and restarting the shutdown
sound more like another hack to me.
An application should not prevent a user from shutting down his/her machine.
Sensitive tasks like flushing to the HDD (that are must to be done before
shutdown) involve a kernel mode part of it and the application won't die
untill the kernel mode (drivers or OS) is done with it.
That's why I've asked you about your requirements. I'm not sure what "clean
stages" mean but maybe it is possible that you can redesign your application
so it can tolerate the presence of leftovers from the previous session.
After all if user kills your process (TerminateProcess) it won't clean up.
-Kirk
Viktor Kushnir
"Kirk Ferdmann" <kirk_f...@nospam.hotmail.com> wrote
> That's why I've asked you about your requirements. I'm not sure what
"clean
> stages" mean but maybe it is possible that you can redesign your
application
> so it can tolerate the presence of leftovers from the previous session.
> After all if user kills your process (TerminateProcess) it won't clean up.
Thanks Kirk,
It's basically an approach I am taking. I am revising my design to be able
deal with shutdown without its rejection. I am still curious why Microsoft
doesn't expose anything that allows to determine what was the original type
of a termination request, but gives you an opportunity to reject it.
Viktor
Kirk Ferdmann
> I am still curious why Microsoft
> doesn't expose anything that allows to determine what was the original
type
> of a termination request, but gives you an opportunity to reject it.
Since I do not work for Microsoft I can only speculate. I guess they saw
little or no value in exposing such an API. But I agree with you that
rejection in this case has very little value too.
-Kirk