Hi,

I would like to know, whether some of you know any legitimate way of intercepting the application termination process, in its early phases, from the Kernel-Mode?

By legitimate I mean possibilities that are documented and allowed to be used, by Microsoft itself. This indicates that things like kernel hooks are not an option (I would probably like the solution to work on 64 bit platforms in the future).

The first thing one would probably think of is the PsSetCreateProcessNotifyRoutine (http://msdn.microsoft.com/en-us/library/ms802952.aspx) function. The real problem is - as the documentation states:
To be more exact, the routine is called at the very end of process uninitialization, when hardly any threads are left, and most of the process-related kernel information is gone, too.

Because of the above function's behavior, I'm unable to perform some operations on the process in consideration. Hence, I'm searching for a similar interface, though launched a little earlier than the aforementioned one (when, at least, none of the threads have already been killed).

Thanks in advance!

PsSetCreateThreadNotifyRoutine

The PsSetCreateThreadNotifyRoutine routine registers a driver-supplied callback that is
subsequently notified when a new thread is created and when such a thread is deleted.

..maybe.

@BanMe sure, if I only knew a way of distinguishing thread termination caused by the process being killed, from normal Exit/TerminateThread usage...

A function supposed to figure out whether the specified process is currently in a shut-down state or not might exist, however I'm not aware of such... Let me know if you do.

Hi j00ru

As we can see from the WRK, the PspCreateThreadNotifyRoutine callback is called fairly early in PspExitThread(IN NTSTATUS ExitStatus).

I found that in XP the ExitStatus is available off the stack at [ebp+8] while within the ThreadNotifyRoutine callback. When I terminated an app normally or with Taskmgr, the ExitStatus was the normal 0. But when killed with ProcessExplorer the ExitStatus == 1 (STATUS_WAIT_1 ?).

So, for that case at least, ExitStatus could indicate an "abnormal" termination perhaps?

One could also check ETHREAD->ExitStatus, or EPROCESS->ExitStatus, or EPROCESS->LastThreadExitStatus, or whatever, from within the callback, but those field locations are of course OS-dependant.

But then there's also the kernel equivalent of GetExitCodeThread => NtQueryInformationThread or GetExitCodeProcess => NtQueryInformationProcess to also retrieve lpExitCode.

Cheers,
Kayaker

Hi Kayaker,
Sorry for the delay, been kind of busy recently...

Yeah, it is probably possible to distinguish some abnormal termination from a regular one, but that's not particularly the problem I'm struggling with.
Specifically, what I am trying to achieve is to know when a thread is terminated because of TerminateThread, and when caused by TerminateProcess.

In advance to possible future responses: I've also come across to some "external" kernel functions like:

PsGetProcessExitProcessCalled
PsGetProcessExitStatus
PsGetProcessExitTime

They are all exported nt! symbols, however all of the internal EPROCESS structure fields used by them, are apparently set after all the Thread notify routines are called. Therefore, I'm still searching for a working solution...

Thanks for your advices!

Have you looked at the Ob filtering functions?