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?

--
There are many self-professed Christians who seem to think that because
they believe in Jesus' sacrifice they can reject Jesus' teachings about
how we should treat others. In this country, they show that they reject
Jesus' teachings by voting for Republicans.

On 7/19/2023 1:10 PM, Kenny McCormack 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?
>

To answer the question properly, opens a can of worms :-) While sitting
in your shell, you can issue the first command, look for a response,
then issue the second command if the process did not respond as you expected
it to.

taskkill /im notepad.exe # graceful, offer user to "save text files" opportunity
taskkill /F /im notepad.exe # hammer time, notepad.exe just gets to... die.
# Any open text files with changes, the changes are lost.

These are equivalent to signal() in other OSes, so would
have numerical equivalents. Presumably, the /F "cannot be intercepted"
and is an unconditional signal. I will not attempt to reproduce a
table of signal values, because you'll laugh at me.

Even when the OS does a GUI-based shutdown, it can sequentially do those
two lines for you, and offers a GUI opportunity to "stop the shutdown",
go back, and save your Notepad text file.

*******

Technically, how you treat a Metro App is different. This is, of course,
just bullshit. They didn't even draw a proper state diagram. At a guess
(I'm not a programmer), this is similar to a DOS TSR. Even Linux/Unix had
an equivalence, where to speed up scripts, you could run processes such that
the next instance could start faster. Which is evidence of suspension rather
than termination. Thus, there are vague equivalents in other OSes (maybe).

If you submit a Metro program to Microsoft Store, support for this diagram is mandatory.
In Task Manager, right now, you can see things in Suspend state. A common occurrence.
How does TaskKill interact with these ? Hmmm.

https://learn.microsoft.com/en-us/windows/uwp/launch-resume/images/updated-lifecycle.png

From the Suspend ball for Metro, there is a path like this.

+---------+ (low on memory)
| Suspend |--------------------- Terminate ---- Zombie ------ (all gone)
+---------+

The Zombie state is when the OS tries to harvest the resources of a killed
program, and the harvesting is failing to work properly. Yes, I have seen
the word "Zombie" in Task Manager! That's how I can draw that diagram,
from first hand experience. I have not seen a Zombie in about five years,
and there is a potential for it to no longer exist (a refusal to put the
word Zombie in Task Manager). But I have to leave it in the diagram, just in case.

You really need something like an Ask Raymond (raymondcc) article, to
get some of these things properly explained.

The topic needs a better treatment than I can give.

Just be warned, that this is a toy OS, and is "not suitable for running medical devices" :-/
For example, the loader will refuse to run, while the garbage collector is running
(on a single thread). You can have a "20 second outage" on this OS, in a sense.

There is no updated Hypervisor diagram, showing what is going on in other
rings, while you're drinking your coffee. It's an undocumented toy OS.
You're not allowed to look at the sandbox, WSL kernel details, and so on.
Or even the torturous path of WSLg graphics through Terminal Services graphics path.
The Task Manager has no rigorous accounting for machine activity any more
(connect a Kill-O-Watt meter to the computer cord, if you want to know
"something is running" on your machine). For example, Memory Compressor is
running, but there is no longer an entry for it in Task Manager. If you use
resmon.exe , you can see it running in there.

https://i.postimg.cc/NfLS15dv/memory-compressor.gif

Paul

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.

Kenny,

> 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?

It works pretty-much the same as with shutting a computer down.

You can momentarily press the power button to ask the computer to shut
itself down, or you can hold the power button down for about 5 seconds.

Which one do you use and why ?

Regards,
Rudy Wieser

In article <u9air3$2j5vr$1@dont-email.me>, R.Wieser <address@is.invalid> wrote:
>Kenny,
>
>> 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?

The takeaway that I am getting from the responses on this thread is:

1) With /F, it does an actual kill, in the same style as what I am used
to on Unix.
2) Without /F, it really doesn't do a kill at all. It just send a
WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
actually is), asking the app to do a normal exit.

I never understood the point of case 2 above, but that does seem to be the
general mindset of the people who program GUI/"end-user" OSes. Always do
it the complex way first... (Yes, I do get what some of the responses have
said about it being handy when the system is shutting itself down, but it
doesn't seem ot me to be particularly ideal when the user is explicitly
invoking a "kill" functionality)

My personal mindset is that if we are at the point of using a task killer to
kill processes, we've already given up on a "graceful" shutdown. If the
app was still in a state where it makes sense to try for a graceful
shutdown, I'd just use the app's own machinery (menu
option/hotkwy/whatever) to do it. The fact that I'm using the kill program
to do it, indicates we're already past that stage.

Anyway, thanks for the responses. I think we can consider this closed.

--
Trump has normalized hate.

The media has normalized Trump.

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> In article <u9air3$2j5vr$1@dont-email.me>, R.Wieser <address@is.invalid> wrote:
>>Kenny,
>>
>>> 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?
>
> The takeaway that I am getting from the responses on this thread is:
>
> 1) With /F, it does an actual kill, in the same style as what I am used
> to on Unix.
> 2) Without /F, it really doesn't do a kill at all. It just send a
> WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
> actually is), asking the app to do a normal exit.
>
> I never understood the point of case 2 above, but that does seem to be the
> general mindset of the people who program GUI/"end-user" OSes. Always do
> it the complex way first... (Yes, I do get what some of the responses have
> said about it being handy when the system is shutting itself down, but it
> doesn't seem ot me to be particularly ideal when the user is explicitly
> invoking a "kill" functionality)
>
> My personal mindset is that if we are at the point of using a task killer to
> kill processes, we've already given up on a "graceful" shutdown. If the
> app was still in a state where it makes sense to try for a graceful
> shutdown, I'd just use the app's own machinery (menu
> option/hotkwy/whatever) to do it. The fact that I'm using the kill program
> to do it, indicates we're already past that stage.
>
> Anyway, thanks for the responses. I think we can consider this closed.

Just because a process becomes unresponsive to user input (keyboard or
mouse) does not mandate it is also unresponsive to a WM_CLOSE request.
I've had "dead" programs that I cannot use the keyboard or mouse to
control, but taskkill will still works to get the program to gracefully
close, like write its buffers instead of losing that data. *IF* you can
still use the keyboard or mouse in the program then you should also be
able to use the incorporate exit routine in that program, which also
means you wouldn't be trying to taskkill at all. If you are trying to
use taskkill, user input isn't available with the program, but the
program might still respond to a WM_CLOSE request. So, you first try to
exit using the program, if that fails then taskkill, and if that fails
then taskkill /f.

Kenny,

> 2) Without /F, it really doesn't do a kill at all. It just send a
> WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
> actually is), asking the app to do a normal exit.
>
> I never understood the point of case 2 above,

The difference is that when you /ask/ a process to terminate itself you give
it a chance to cleanup after itself (close files etc.), while the "/F" just
tells the OS to remove the process from its tasklist and free its memory.

IOW, if the process had data it didn't write/update (to file or other) than
that data is lost* - possibly causing problems later on.

*same as shutting down the 'puter using the "hold the power button 5 sec."
way - or yanking an USB (thumb)drive instead of asking the OS to eject
(unmount) it first.

Regards,
Rudy Wieser

On 7/23/2023 3:11 AM, R.Wieser wrote:
> Kenny,
>
>> 2) Without /F, it really doesn't do a kill at all. It just send a
>> WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
>> actually is), asking the app to do a normal exit.
>>
>> I never understood the point of case 2 above,
>
> The difference is that when you /ask/ a process to terminate itself you give
> it a chance to cleanup after itself (close files etc.), while the "/F" just
> tells the OS to remove the process from its tasklist and free its memory.
>
> IOW, if the process had data it didn't write/update (to file or other) than
> that data is lost* - possibly causing problems later on.
>
> *same as shutting down the 'puter using the "hold the power button 5 sec."
> way - or yanking an USB (thumb)drive instead of asking the OS to eject
> (unmount) it first.
>
> Regards,
> Rudy Wieser

This is an example of some code, that attempts to allow a program
to "clean up", when it received a control-c in a shell window.

The program does not absolutely need it. It was an experiment, to see
if program termination was any faster when done this way. And it
really was not. But that's why you do experiments. For the hell of it.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <windows.h>

/* gcc -o malloc.exe -Wl,--large-address-aware malloc.c */

BOOL WINAPI handler(DWORD dwCtrlType) /* This one will not intercept a Task Manager kill */
{ if (CTRL_C_EVENT == dwCtrlType)
{
exit(0); /* Cleanup code would go here, like offering to save files */
}
return FALSE;
}

int main (int argc, char *argv[])
{ SetConsoleCtrlHandler(handler, TRUE);

__int64 time1 = 0, time2 = 0, freq = 0;
QueryPerformanceCounter((LARGE_INTEGER *) &time1);
QueryPerformanceFrequency((LARGE_INTEGER *)&freq);

int i = 0;
void *m;

/* Fill up memory, print something on the screen while doing so. */

while ( (m = malloc(1024*1024)) != NULL ) {
memset(m,0,1024*1024);
i++;
QueryPerformanceCounter((LARGE_INTEGER *) &time2);
printf("%05d megabytes t=%010.6f\n", i, (float)(time2-time1)/freq);
}
}

Running a program like that, does not cause pagefile.sys usage on modern Windows.
Running two instances, there is a short transient where some "leakage" may
go to the pagefile. It's possible the Memory Compressor is involved, but the
Memory Compressor can no longer be seen in Task Manager, and a second provided
Windows program is needed to see it instead. The Task Manager "comes with no guarantees"
now, with regard to machine usage.

Using a power meter, connected to the PC line cord, is a good "process status"
solution. You can't hide usage of CPU, when the power meter is watching you.

Paul

In article <o94iqrlqg7ap$.dlg@v.nguard.lh>, VanguardLH <V@nguard.LH> wrote:
....
>Just because a process becomes unresponsive to user input (keyboard or
>mouse) does not mandate it is also unresponsive to a WM_CLOSE request.

Point taken, although in Windows, it is usually all or nothing.
The list of actions to take is much shorter than in Unix and for most
people, most of the time, a fast harsh kill as the first thing to try is
generally reasonable.

>I've had "dead" programs that I cannot use the keyboard or mouse to
>control, but taskkill will still works to get the program to gracefully
>close, like write its buffers instead of losing that data. *IF* you can
>still use the keyboard or mouse in the program then you should also be
>able to use the incorporate exit routine in that program, which also
>means you wouldn't be trying to taskkill at all. If you are trying to
>use taskkill, user input isn't available with the program, but the
>program might still respond to a WM_CLOSE request. So, you first try to
>exit using the program, if that fails then taskkill, and if that fails
>then taskkill /f.

Interestingly enough, the specific app in question will mis-behave if it is
shutdown "normally" or killed w/o /F. Only killing it via /F ensures a
proper shutdown. Funny that.

And, no, I don't have the source code for the app.

--
When someone tells me he/she is a Christian I check to see if I'm
still in possession of my wallet.

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Interestingly enough, the specific app in question will mis-behave if
> it is shutdown "normally" or killed w/o /F. Only killing it via /F
> ensures a proper shutdown. Funny that.
>
> And, no, I don't have the source code for the app.

Does the program exit using an Exit, Quit, or other similarly named
element within the program? That is, if you go into the program, can
you ask it to exit? If so, does it exit upon request?

Is [part of] the program running as a service?

If "taskkill /f" is the only way to get the program to exit, one way to
kill it on shutdown is to define an event in Task Scheduler. Alas,
while there is an "on logon" event you can trigger the scheduled event,
there is no matching "on logoff" event. You can use "on event" and
specify the Event ID for logoff (you can see the IDs in the event
viewer), but I'd have to do further research to see which event ID you'd
specify in the Task Scheduler task that would equate to a logoff event.
I think it's event ID 4647, but I'd have to check by testing. One
defined, and the correct event ID was specified, the program specified
by the scheduled task would run at shutdown.

https://www.manageengine.com/products/active-directory-audit/kb/logon-logoff-events/event-id-4647.html

Instead you could specify commands using the Logoff event. There are
both Logon and Logoff events that will run commands on startup and
shutdown. The problem with logon and logoff events is you need to use
the policy editor to define them. You have Windows 10, but no mention
if it is the Home edition which lacks the policy editor.

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789190(v=ws.11)

I haven't used these logon/logoff/startup/shutdown scripts in MANY
years. The article says to specify a script, so you may not be able to
directly enter the "taskkill.exe /f" command line. Maybe "cmd.exe /c
taskkill.exe /f" or "cmd.exe start /b /c taskkill.exe /f" would work.
Else, you might have to create batch file that runs "taskkill.exe /f",
and you point the Logoff event at that .bat file.

Else, if it works, you'll have to remember to taskkill /f on the program
before you shutdown. Create a shortcut to run the command, and remember
to click the shortcut before you shutdown.

On 7/25/2023 9:38 AM, Kenny McCormack wrote:
> In article <o94iqrlqg7ap$.dlg@v.nguard.lh>, VanguardLH <V@nguard.LH> wrote:
> ...
>> Just because a process becomes unresponsive to user input (keyboard or
>> mouse) does not mandate it is also unresponsive to a WM_CLOSE request.
>
> Point taken, although in Windows, it is usually all or nothing.
> The list of actions to take is much shorter than in Unix and for most
> people, most of the time, a fast harsh kill as the first thing to try is
> generally reasonable.
>
>> I've had "dead" programs that I cannot use the keyboard or mouse to
>> control, but taskkill will still works to get the program to gracefully
>> close, like write its buffers instead of losing that data. *IF* you can
>> still use the keyboard or mouse in the program then you should also be
>> able to use the incorporate exit routine in that program, which also
>> means you wouldn't be trying to taskkill at all. If you are trying to
>> use taskkill, user input isn't available with the program, but the
>> program might still respond to a WM_CLOSE request. So, you first try to
>> exit using the program, if that fails then taskkill, and if that fails
>> then taskkill /f.
>
> Interestingly enough, the specific app in question will mis-behave if it is
> shutdown "normally" or killed w/o /F. Only killing it via /F ensures a
> proper shutdown. Funny that.
>
> And, no, I don't have the source code for the app.
>

Is this a TAP or TUN networking application ?

For graphical applications, if you were running the original
Windows 8.0, you could use Alt-F4 to exit the application.
It is an alternative way to Quit.

If you click the desktop, then use Alt-F4 at that moment, it will
trigger the Windows shutdown menu. This is something I use all the time.

It is what you use, when the corner "X" graphical decoration,
has gone missing.

A program with a signal handler, may be able to ignore your
input. Perhaps your first VPN program, is doing stuff like this,
while it "avoids leaking private data". VPN software people are
crazy enough to do stuff like this.

There is one flavor of signal that cannot be intercepted (just
like on the other platforms you work on). And that's what your
TaskKill thing is doing. That's the "hammer" signal.

Find a backgrounder on the program-with-the-weird-behavior
and I bet there is a story involved. Stuff like this
doesn't happen to my copy of HelloWorld.

And sure, there are things you can't kill. I've had things
listed as "Zombie" in Task Manager. I had a program with
no name and missing strings for other metadata, running in
Task Manager, and Windows did not mind in the least. I was
expecting malformed programs to be "killed with prejudice"
but no, did not happen. I also had a program with "an impossible parent"
listed in Task Manager.

Why does Microsoft allow shit like this to exist ??? These
are not desirable characteristics and allowing such, serves no purpose.
Then you wonder why it's easy to inject malware.

Paul