Detect 'End Process' in application

[SeC]

Hi.
Is there any way to detect if application is being killed by 'End
Process' via Task Manager ?

 

[Willy Denoyette [MVP]]

Hi.
Is there any way to detect if application is being killed by 'End
Process' via Task Manager ?

No there isn't, and that's why you should never kill an application unless the application
is blocked and none of it's threads can ever make any progress.

Willy.

 

[SeC]

Willy Denoyette [MVP] napisal(a):

No there isn't, and that's why you should never kill an application unless the application
is blocked and none of it's threads can ever make any progress.

Willy.

Yeah, I know that, but person who uses my application don't. He can
terminate process just 'because' and I need to perform some actions
when this happen. So there is nothing I can do about it ?

 

[Willy Denoyette [MVP]]

Willy Denoyette [MVP] napisal(a):

Yeah, I know that, but person who uses my application don't. He can
terminate process just 'because' and I need to perform some actions
when this happen. So there is nothing I can do about it ?

As I said, No there isn't. Educate your users not to kill processes or remove "Task manager"
from the task bar by applying group policies.

Willy.

 

[Andrew Meador - ASCPA, MCSE, MCP+I, Network+, A+]

I may be putting my foot in my mouth here, and I don't have a
solution, but I think you can do this some how. I'm sure it would take
some advanced coding, but I think it can be done. I have dealt with
viruses that when you kill the process it starts right back up. I've
also had processes that have ran in such a way that Task Manager cannot
kill them at all. If the application is truely not 'locked up' and is
running, is there no que or system call that could be monitored to see
it this process in in the que or having a system call issues to kill
it, and then respond by doing some cleanup - maybe cancelling itself
from the que/system call, doing cleanup, and closing properly? If the
application is truely 'locked' then it wouldn't matter anyway.
I am not good at the current programming languages and such, but I
find things like this to fit into that 'never say never' category.
There is usually a way to do almost anything in code.
Also, you're assuming that this programmer is in a position to
enforce group policy. I write retail applications and have no power
over what is enforced though group policy, assuming they are even
running in a server based network. Messing with local policies when you
install software on someone elses machine is not good practice. And
considering you are an MVP, you have been 'computering' for a bit and
you know users will not listen to you many times and will do what they
want, when they want, and then tell you they didn't do it!
Look into this more, I'll bet you 99.99% chance this can be done
some way.

 

[Willy Denoyette [MVP]]

I may be putting my foot in my mouth here, and I don't have a
solution, but I think you can do this some how. I'm sure it would take
some advanced coding, but I think it can be done. I have dealt with
viruses that when you kill the process it starts right back up. I've
also had processes that have ran in such a way that Task Manager cannot
kill them at all. If the application is truely not 'locked up' and is
running, is there no que or system call that could be monitored to see
it this process in in the que or having a system call issues to kill
it, and then respond by doing some cleanup - maybe cancelling itself
from the que/system call, doing cleanup, and closing properly? If the
application is truely 'locked' then it wouldn't matter anyway.
I am not good at the current programming languages and such, but I
find things like this to fit into that 'never say never' category.
There is usually a way to do almost anything in code.
Also, you're assuming that this programmer is in a position to
enforce group policy. I write retail applications and have no power
over what is enforced though group policy, assuming they are even
running in a server based network. Messing with local policies when you
install software on someone elses machine is not good practice. And
considering you are an MVP, you have been 'computering' for a bit and
you know users will not listen to you many times and will do what they
want, when they want, and then tell you they didn't do it!
Look into this more, I'll bet you 99.99% chance this can be done
some way.

Well, let me be more specific, I'm talking about the "kill" in OP's question while he's
asking about the "End process". So my previous answer "No it can't be done" might be wrong,
all depends on why the user decides to use 'Taskman' to terminate an application, let me
explain.
Using "End task" in taskman will try to "End a process" or try to "Kill " a process,
taskman's "End process" will ask the OS to send a WM_CLOSE message to the UI thread
messagequeue or a CTRL_CLOSE_EVENT to a console program. Both of these can be handled by the
offending application. If the application does not respond to the message or the event in a
timely fashion, the OS will "kill" the process by calling Win32's "TerminateProcess" API.
The latter cannot be trapped, simply because no more user code will run in that process, the
user portion of a process is cleaned up without returning a thread quantum to the process,.
Note that here I'm saying user portion, a process that get's stucked into kernel space (say
in a driver) won't go away completely (only the user's portion will) if the (badly behaving)
driver doesn't clean-up and return to the OS, this is what you may have noticed using
taskman.
Now the whole question is - why does the end-user use taskman to *end* a task? Isn't it
easier to close/exit the application in a normal way? My guess is that the application is
stucked somewhere (endless loop, dead-locked, locked in kernel, etc..) and the user has no
other means than using "taskman" to terminate the application, but *if* the application is
stucked somewhere it cannot handle the message/event and it will get "killed" by
'TerminateProcess" which cannot be trapped and that was my exact point.

Willy.

 

[Lucian Wischik]

Using "End task" in taskman will try to "End a process" or try to "Kill " a process,
taskman's "End process" will ask the OS to send a WM_CLOSE message to the UI thread
messagequeue or a CTRL_CLOSE_EVENT to a console program. Both of these can be handled by the
offending application. If the application does not respond to the message or the event in a
timely fashion, the OS will "kill" the process by calling Win32's "TerminateProcess" API.

Now the whole question is - why does the end-user use taskman to *end* a task? Isn't it
easier to close/exit the application in a normal way?

I use the taskman "end task" as the standard way to exit several of my
utilities -- the small ones that run in the background and have no
user-interface as all. E.g. my "keymouse" program which turns the
right-alt-key into a virtual right-mouse-button (for people whose mice
have only one button...)
http://www.wischik.com/lu/Programmer/Keymouse

And exactly as you say, all I do is handle the WM_CLOSE message to do
the tidying up.



As for educating the user not to use EndProcess? My instinct is to
write a registry key when the application starts, and clear it when
the application ends. Upon application startup I check the key. If it
has been set then I pop up a box saying "Sorry, this application seems
to have crashed last time it was run. Where possible, try to exit the
application through File>Exit."

 

[Willy Denoyette [MVP]]

I use the taskman "end task" as the standard way to exit several of my
utilities --

Why not use the "regular" way to end a task, that is click close or Exit, is beyond me. My
guess is that you talk as a developer, you know exactly how your utilities behaves when they
get terminated from an 'external' program, a regular user should never use taskman to end a
task, he simply doesn't (and shouldn't) know what's happening when he 'kills' a task from
Taskman. I know <start rant> people don't care that much about this all and keep running as
"administrator", kill other processes, inspect memory consumption using taskman without
knowing what memory really is, blame Windows, MSFT etc..when things go wrong when they
(Inadvertly ?) killed Winlogon or CSRSS.EXE etc., it's great to see Vista trying to get an
end to this, but as the saying goes "bad habbits never die", that's why we see a lot of
interest in turning off UAC<end rant>.


the small ones that run in the background and have no

user-interface as all. E.g. my "keymouse" program which turns the
right-alt-key into a virtual right-mouse-button (for people whose mice
have only one button...)
http://www.wischik.com/lu/Programmer/Keymouse

And exactly as you say, all I do is handle the WM_CLOSE message to do
the tidying up.

Here you mean your UI type utilities, right?, WM_CLOSE is only posted to UI threads.

As for educating the user not to use EndProcess? My instinct is to
write a registry key when the application starts, and clear it when
the application ends. Upon application startup I check the key. If it
has been set then I pop up a box saying "Sorry, this application seems
to have crashed last time it was run. Where possible, try to exit the
application through File>Exit."

Why not handle the WM_CLOSE and tell the user he should terminate the application through
File>Exit?


Willy.

 

[Lucian Wischik]

Why not use the "regular" way to end a task, that is click close or Exit, is beyond me.

As I said, for minimal background utilities that are too small for a
UI to be worth it (e.g. a system tray icon). So there is no place to
click Close or Exit. The task manager "Task List" is the neatest place
to list the running utility and be able to close it.

Here you mean your UI type utilities, right?, WM_CLOSE is only posted to UI threads.

Come on, this is Windows. Even utilities without a UI still often need
a UI thread. (e.g. in the example I posted, it's disallowed to install
a keyboard hook unless you have a UI thread.)

Also, if you want the application to appear in the task list so that
users can close it, then it needs a UI thread and a window, even
though that window is invisible and WS_EX_NOACTIVATE.

Why not handle the WM_CLOSE and tell the user he should terminate the application through
File>Exit?

The exercise is to educate the user not to use "End Process".

When the user terminates the program through "End Task" (->WM_CLOSE)
or clicking on the close box (->WM_CLOSE) or File>Exit, the original
poster is able to trap this and do the cleanups he needs.

He was concerned about users who use "End Process" where he can't trap
it and clean up.

Anything that produces WM_CLOSE is fine, from his perspective, so
there's no need to educate the user against it.

 

[Willy Denoyette [MVP]]

As I said, for minimal background utilities that are too small for a
UI to be worth it (e.g. a system tray icon). So there is no place to
click Close or Exit. The task manager "Task List" is the neatest place
to list the running utility and be able to close it.


Come on, this is Windows. Even utilities without a UI still often need
a UI thread. (e.g. in the example I posted, it's disallowed to install
a keyboard hook unless you have a UI thread.)

A process that has a UI thread (that is, has a Window registered, a message queue and a
message pump) is what I call a UI style application (or utility as you named it) , it
doesn't matter whether the window is invisible or not.

Also, if you want the application to appear in the task list so that
users can close it, then it needs a UI thread and a window, even
though that window is invisible and WS_EX_NOACTIVATE.



The exercise is to educate the user not to use "End Process".

When the user terminates the program through "End Task" (->WM_CLOSE)
or clicking on the close box (->WM_CLOSE) or File>Exit, the original
poster is able to trap this and do the cleanups he needs.

He was concerned about users who use "End Process" where he can't trap
it and clean up.

Anything that produces WM_CLOSE is fine, from his perspective, so
there's no need to educate the user against it.

So, you are telling your users that it's OK to use "End task" but NOT "End process" from
Taskman and all of them do follow this advise? Well, that' s great for you, but our policy
is somewhat different, all users that logon into their domain account to run business
critical applications cannot use taskman (through GPM), this is something we learned the
hard way since Windows NT4 was introduced in the company a decade ago, this is not about
trusting your users (you can't trust all of them), this is about safety. And, No, we don't
install utilities that need to be started/terminated by the user that don't have a minimal
UI with 'close' or 'exit'.

Willy.