PC power button - Slightly off-topic

I think a "short" press causes that response. IIRC, the "hold for 4 seconds" behavior is done in hardware (to deal with the problem of a hung processor). I *vaguely* remember that from designing with COMBO chips in years past (I suspect most of those are no longer made as the floppy is a thing of the past)

Depends on the operating system. Of course, the application doesn't have to heed these warnings...

In Linux/Unix/Posix/... its the SIGTERM and SIGKILL signals.

Mel.

I think it's 10 seconds.

And yes, if you're not doing a hard power-down the OS will tap the applications on the shoulder, and point to the exit sign.

Be aware that in Windows some applications may refuse and OS will not shut down. We had to look for a workaround for UPS to shutdown a PC with Citect Scada running on it.

Tom

Do you mean something like this (windows, windows embedded etc.)?

InitiateSystemShutdownEx(NULL, NULL, 0, TRUE, TRUE, SHTDN_REASON_MAJOR_HARDWARE)

For details see the windows SDK.

(In windows)you first need to setup permissions: Taken from an example watchdog service: LUID localUid; HANDLE hToken; TOKEN_PRIVILEGES tokenPrivileges;

. . . . . if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY | TOKEN_ADJUST_PRIVILEGES, &hToken)) MessageBox(NULL, "OpenProcessToken Error", "Setup Error", MB_OK | MB_SERVICE_NOTIFICATION); if (!LookupPrivilegeValue(NULL, SE_SHUTDOWN_NAME, &localUid)) MessageBox(NULL, "VIBMON: LookupPrivilegeValue Error", "Setup Error", MB_OK | MB_SERVICE_NOTIFICATION);

tokenPrivileges.PrivilegeCount = 1; tokenPrivileges.Privileges[0].Luid = localUid; tokenPrivileges.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

if (!AdjustTokenPrivileges(hToken, FALSE, &tokenPrivileges, sizeof(TOKEN_PRIVILEGES), (PTOKEN_PRIVILEGES) NULL, (PDWORD) NULL)) { msgString until the OS has done its shutdown silly walk.

Yup. Usually you count to ten seconds by going "one thousand one, one thousand two, ...".

With Windows and the power button it's "goddammit one, goddammit two, ...".

In Windows there is the WM_QUERYENDSESSION message:

-- Chris Burrows CFB Software

There is a registry setting that forces termination of hung processes instead of displaying a message and waiting until doomsday for a user response.

There is also a "hung process" timeout value which controls when the auto kill kicks in. This is separate from the normal process shutdown timeout.

See:

George

In my case Citect wasn't hung, it was designed not to shut down as this software often controls industrial systems etc. - it simply replies to Windows that it needs to run and shutdown doesn't happen, Windows happily continues to run. Citect can be stopped by authorized user and then you can shutdown the computer. We used it in less critical application and wanted a clean shutdown when no operator is around, power went off and UPS battery is about to give up.

Tom

Processes that are not hung can actively choose to block the shutdown in Windows - then they need to be closed manually (either through the application itself, or killing it with task manager).

It is also possible for processes in windows to become unkillable. I've seen this happen with software that talks to USB devices, and doesn't handle device disconnections properly, or software that doesn't handle network hiccups well. As far as I know, the reset button is the only way to stop these processes.

Thanks for all the informative posts. Got everything I needed and more.

-jim

Yes, both processes can refuse WM_QUERYENDSESSION *unless* the shutdown request specifies that they be forced closed.

The registry setting "AutoEndTasks" terminates processes that are either hung or which refuse to shut down. Once the process continues past the relevant timeout period - "WaitToKillAppTimeout" for normal processes or "WaitToKillServiceTimeout" for services - it is nuked with prejudice.

AutoEndTasks results in the shell calling InitiateSystemShutdown(Ex)() with the parameter bForceAppsClosed = true. Applications are first asked to shut down (QUERYENDSESSION) and are forced if they refuse or do not answer within the timeout period. If the process answers QUERYENDSESSION affirmative, ENDSESSION is sent normally so the process can exit gracefully.

AutoEndTasks is _not_ the same as ExitWindowEx() with EWX_FORCE, which sends neither QUERYENDSESSION nor ENDSESSION but rather terminates processes immediately.

"AutoEndTasks" can result in loss of data if processes refuse to shut down when asked. Processes need to catch ENDSESSION if they must shut down gracefully. You can always reply affirmative to QUERYENDSESSION and start your graceful shut down - the process won't be terminated until after it returns from ENDSESSION.

No question, drivers can hang and require a hardware reset. It doesn't matter how carefully they are written ... if the hardware is at all flaky - which plug-n-play things have a penchant for - the driver can get messed up.

However, none of this stops a properly written application from terminating gracefully. "It's stuck waiting on the driver ... " is, IMO, a lame excuse.

George

And people say that Linux is hard to understand...

Thanks for that information - this is perhaps worth trying if something gets stuck in the future.

It seems strange that the AutoEndTask behaviour is not enabled by default - if you ask the system to shut down, you want all the programs to be stopped no matter what it takes. And forcefully killing them like this is still much nicer than the reset or power button, which is the only alternative.

Is there any way to kill individual applications more forceably than can be done with task manager (or process explorer, etc.)? i.e., can you get the AutoEndTask effect but only apply it to one hung process without shutting down the whole system? A sort of "kill -9" for windows.

Windows likes to use shutdown as a time to make sure that all software updates are downloaded and installed. I think (not sure) lack of AutoEndTask is what lets this happen.

Mel.

You would think MS could figure out a way to distinguish software updates and hung processes...

The inability to stop hung processes pre-dates windows system of updating software when you least expect it and least want it, but that may well be part of the reason.

Updates are actually installed at boot ... not at shutdown. However, the registry entries that control the install may be in flux at the time of the shutdown.

George

It's not enabled by default because data can be lost when a process is forcibly terminated. Most people desire that only hung programs be killed, but AutoEndTasks will also kill programs that just happen to be busy when asked.

Yes: attach with "controlling process" access rights (i.e. as a debugger). See OpenProcess() and TerminateProcess().

Be aware that TerminateProcess() does not detach DLLs before killing the process, so shared DLLs may retain allocated state for the process, and if the DLLs implement COM/ActiveX objects their reference counts may be messed up until reboot.

You have to own the process or be a member of the Administrator or SYSTEM group to get modify access rights on a process.

FWIW: you don't need to write it yourself (though it is simple). There are a number of command-line and GUI "kill" programs for Windows ... M$ even provides one in its server tools distribution.

George

I'm not thinking that tasks should be killed instead of being asked to die, but that unresponsive tasks that refuse to die should be killed. The "AutoEndTask" behaviour should come automatically after normal shutdown processing has failed to work - the alternative is a hard reset which risks all sorts of mess because windows itself hasn't stopped properly (who cares if a hung process loses data?).

I'll give that a shot next time something has stuck beyond "normal" killing. It doesn't happen often, fortunately.