Hi,
-
I have a process running in my Filter Driver.
-
If this process is getting killed from task manager.
-
Then what are the ways to know in the Filter Driver that particular
process has been killed? And how can we do that?
Thanks & Regards,
Maitri Ved| E-DRM | Tech Mahindra
Oberoi Garden Estate, Chandivali, Mumbai - 72
* Office: +91-22-66882000 | Extn: 8092
Email: xxxxx@techmahindra.com mailto:xxxxx
www.techmahindra.com http:</http:>
============================================================================================================================
Disclaimer:
This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/Disclaimer.html internally within Tech Mahindra.
============================================================================================================================</mailto:xxxxx>
Maitri Ved wrote:
Hi,
-
I have a process running in my Filter Driver.
-
If this process is getting killed from task manager.
-
Then what are the ways to know in the Filter Driver that particular
process has been killed? And how can we do that?
PsSetCreateProcessNotifyRoutine stuff wouldn’t be good enough?
This might not really be atomic / synchronized with for ex. a
communication on another thread with that particular process. The filter
might just be sending a message when the user kills the process.
Sandor LUKACS
You should open a handle to the process and wait on it, the same as in user mode.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maitri Ved
Sent: Thursday, November 06, 2008 3:42 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] How to know that process is getting killed outside the filter driver?
Hi,
- I have a process running in my Filter Driver.
- If this process is getting killed from task manager.
- Then what are the ways to know in the Filter Driver that particular process has been killed? And how can we do that?
Thanks & Regards,
Maitri Ved| E-DRM | Tech Mahindra
Oberoi Garden Estate, Chandivali, Mumbai - 72
? Office: +91-22-66882000 | Extn: 8092
Email: xxxxx@techmahindra.commailto:xxxxx
www.techmahindra.comhttp:</http:>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
============================================================================================================================
Disclaimer:
This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally and http://tim.techmahindra.com/Disclaimer.html internally within Tech Mahindra.
============================================================================================================================</mailto:xxxxx>
That is not the correct solution. You should open a handle to the process and wait on it, as in user mode.
The create notify routines should be a choice of last resort and not the first thing that one turns to with respect to this sort of thing. Waiting on the process handle is the way that this is designed to work.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Sandor LUKACS
Sent: Thursday, November 06, 2008 4:17 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to know that process is getting killed outside the filter driver?
Maitri Ved wrote:
Hi,
-
I have a process running in my Filter Driver.
-
If this process is getting killed from task manager.
-
Then what are the ways to know in the Filter Driver that particular
process has been killed? And how can we do that?
PsSetCreateProcessNotifyRoutine stuff wouldn’t be good enough?
This might not really be atomic / synchronized with for ex. a
communication on another thread with that particular process. The filter
might just be sending a message when the user kills the process.
Sandor LUKACS
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Skywing wrote:
I’ve never used a callback for
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION, but perhaps
stream handle context could be used here. In it’s context cleanup
routine, it could notify UM or whatever?
Perhaps use a combination of that callback and test for File_Execute in
the create path.
I don’t know what IRQL that callback comes in at, but I presume
passive… And I also assume Context can
be accessed within it.
As usual, I have more steam than my ‘train of thought’ does (horrible
English 3x).
Matt
That is not the correct solution. You should open a handle to the process and wait on it, as in user mode.
The create notify routines should be a choice of last resort and not the first thing that one turns to with respect to this sort of thing. Waiting on the process handle is the way that this is designed to work.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Sandor LUKACS
Sent: Thursday, November 06, 2008 4:17 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to know that process is getting killed outside the filter driver?
Maitri Ved wrote:
> Hi,
>
> 1) I have a process running in my Filter Driver.
>
> 2) If this process is getting killed from task manager.
>
> 3) Then what are the ways to know in the Filter Driver that particular
> process has been killed? And how can we do that?
>
>
>
>
PsSetCreateProcessNotifyRoutine stuff wouldn’t be good enough?
This might not really be atomic / synchronized with for ex. a
communication on another thread with that particular process. The filter
might just be sending a message when the user kills the process.
Sandor LUKACS
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> I’ve never used a callback for
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION, but perhaps
stream handle context could be used here. In it’s context cleanup
routine, it could notify UM or whatever?
No. Stream handle context is associated with the open file object, not with the process. You can only track CloseHandle using this, not ExitProcess.
BTW - this tracking is usually enough 
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih wrote:
No. Stream handle context is associated with the open file object, not with the process.
I understand that, but I have been under the belief for quite some time
that for every process that is executing, at least
one open file object must exist. With that belief, when a process is
terminated - all FO’s associated with it will get a IRP_Cleanup and
will in turn trigger a context tear down (where UM communication is
still available).
Thus with all FO’s in a cleanup state would equal ExitProcess.
You can only track CloseHandle using this, not ExitProcess.
It seems your indicating that a process can still execute after all FO’s
have been
cleaned-up and are awaiting IRP_MJ_Close?
BTW - this tracking is usually enough
Damn, first my guns and now my hammer…
(I don’t mean to argue, but the autodidactic approach often involves
seeing what ‘sticks’…)
Matt
That should only be the case of FILE_OBJECTs for which the process in question has the only handle for, though, I think? If more than one process owns a handle to a FILE_OBJECT, then process deletion will not necessarily trigger IRP_MJ_CLEANUP for all FILE_OBJECTs in the process handle table. I suspect that this will be the case if a file handle is duplicated out of process, or if the process handles are inherited to a new process (e.g. handles opened with the inherit flag set, or a cloned process).
For these cases, it would then logically follow that the process for whicch you receive IRP_MJ_CREATE does not have to be the active process when IRP_MJ_CLEANUP is sent for a particular FILE_OBJECT.
-----Original Message-----
From: Matt
Sent: Friday, November 07, 2008 05:00
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to know that process is getting killed outside the filter driver?
Maxim S. Shatskih wrote:
> No. Stream handle context is associated with the open file object, not with the process.
I understand that, but I have been under the belief for quite some time
that for every process that is executing, at least
one open file object must exist. With that belief, when a process is
terminated - all FO’s associated with it will get a IRP_Cleanup and
will in turn trigger a context tear down (where UM communication is
still available).
Thus with all FO’s in a cleanup state would equal ExitProcess.
> You can only track CloseHandle using this, not ExitProcess.
>
It seems your indicating that a process can still execute after all FO’s
have been
cleaned-up and are awaiting IRP_MJ_Close?
> BTW - this tracking is usually enough
>
Damn, first my guns and now my hammer…
(I don’t mean to argue, but the autodidactic approach often involves
seeing what ‘sticks’…)
Matt
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Good point, and very true.
“Skywing” wrote in message news:xxxxx@ntfsd…
That should only be the case of FILE_OBJECTs for which the process in
question has the only handle for, though, I think? If more than one process
owns a handle to a FILE_OBJECT, then process deletion will not necessarily
trigger IRP_MJ_CLEANUP for all FILE_OBJECTs in the process handle table. I
suspect that this will be the case if a file handle is duplicated out of
process, or if the process handles are inherited to a new process (e.g.
handles opened with the inherit flag set, or a cloned process).
For these cases, it would then logically follow that the process for whicch
you receive IRP_MJ_CREATE does not have to be the active process when
IRP_MJ_CLEANUP is sent for a particular FILE_OBJECT.
- S
-----Original Message-----
From: Matt
Sent: Friday, November 07, 2008 05:00
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to know that process is getting killed outside the
filter driver?
Maxim S. Shatskih wrote:
> No. Stream handle context is associated with the open file object, not
> with the process.
I understand that, but I have been under the belief for quite some time
that for every process that is executing, at least
one open file object must exist. With that belief, when a process is
terminated - all FO’s associated with it will get a IRP_Cleanup and
will in turn trigger a context tear down (where UM communication is
still available).
Thus with all FO’s in a cleanup state would equal ExitProcess.
> You can only track CloseHandle using this, not ExitProcess.
>
It seems your indicating that a process can still execute after all FO’s
have been
cleaned-up and are awaiting IRP_MJ_Close?
> BTW - this tracking is usually enough
>
Damn, first my guns and now my hammer…
(I don’t mean to argue, but the autodidactic approach often involves
seeing what ‘sticks’…)
Matt
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com