Kenny McCormack <
gazelle@shell.xmission.com> wrote:
Bit of background: In Unix, new users soon learn about the "kill" command. Then, after a while, they learn that kill doesn't always work.
Then, after that, they learn about "kill -9", which does (almost) always work.
Thereafter, they never use anything other than "kill -9"; they assume that
is the default command. Why use anything else? (rhetorical question!)
With that said, I've recently started playing around with "TASKKILL" under Windows. I tried to kill something without using /F and it gave error messages that it couldn't kill it and that I should use /F. I re-tried
with /F and it killed it as expected.
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o /F?
2) It there any (practical) reason not to always use /F?
One /requests/ the process to terminate. The app itself does the quit.
The app will flush any buffers to open file handles, and proceed through
its exit routine. As some point in its exit routine, it calls WM_QUIT
to get the dispatcher to kill the process.
The second /forces/ the process to terminate. No asking the app to
quit, but kills the process. If there was data in buffers, that is lost
since the app didn't finish writing it to an open file. This could
leave the file corruption or data loss.
You could ask someone to please step off the chair.
Or you could use a shotgun to shoot the legs off the chair.
taskkill (no /f) just issues the WM_CLOSE signal to the process
taskkill /f uses the TerminateProcess.
One is a graceful exit having the app close itself on request, and is
the preferred exit method if the process is responsive. If it doesn't
respond, like it is hung, it cannot execute its exit routine, or
anything else, so you have to terminate the app's process(es).
However, taskkill is an asynchronous event. Just because it issues
WM_CLOSE to a process (signalling it to request it exit on its own) does
not mean that is when the process exits. taskkill (no /f) just asks the
app to exit. Could take some time before the exit routine completes.
So, you cannot use the return status (errorlevel) from taskkill (no /f)
to know if you should follow with taskkill /f in a batch file. Once
taskkill (no /f) is used, you have to give the process enough time to do
its own exit. Return status from the taskkill program won't tell you
when, and if, the processes got around to finally exiting. You would
need to loop inside a script testing if the process was still around,
and decide when to stop waiting to follow with a taskkill /f.
You might see when shutting down Windows that it reports a process is
taking too long to exit, or is unresponsive. You then get the choice of waiting some more, or killing the exit-pending processes. Better if you
exit the apps before shutting down Windows, so you can see if and when
the app exits. You may even see a prompt from the program, like do you
want to save file changes, but won't see the messages on an OS shutdown.
The default wait time Windows waits for a process to exit after issuing WM_CLOSE is defined in the registry.
Key: HKEY_CURRENT_USER\Control Panel\Desktop
Data item: WaitToKillAppTimeout
If it is not defined, the default of 20,000 milliseconds (20 seconds)
gets used. The shutdown could hang for 20 seconds, or more, waiting for
apps to honor the request that they exit. You could make that longer,
or shorter. Obviously that is a per-user setting, so only affects when
you shutdown Windows after logged into your Windows account. To effect
a global setting to apply to all users (unless they set the above
per-user setting for their account), go to:
Key: HKEY_USERS\.DEFAULT\Control Panel\Desktop
That's how long Windows will wait for responsive processes to exit.
Windows might determine a process is hung, and that timeout is:
Data item: HungAppTimeout
Both settings are string values. The default for HungAppTimeout is 5000 milliseconds (5 seconds).
There are apps that trigger to run on shutdown of Windows. I think the GoodSync program is like that where it can run a backup on shutdown.
You have to up the WaitToKillAppTimeout to prevent Windows from killing
that process too soon. Triggering a backup on shutdown is a bad scheme. Instead the Task Scheduler or a loggoff event should be used. Better
yet is to see if the program has a "shutdown at end of job" option.
Alas, many users just shutdown without remembering to first run the job
that should run just before shutdown, and it then shutdowns the OS.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
