Pattern for a Selective activity monitor

NTFSD
1

I’m working on an activity monitor minifilter that started as minispy.
Currently I’m just catching everything, throwing it in the queue for
processing in the UM client, and then in UM, deciding whether I want to
report any specific event. That can be a significant amount of overhead
processing that I’m throwing away because I’m not interested in it,
depending on what I care about, and where the activity is. I’m wondering if
there is a better pattern than this?

I’ve pondered the option of sending a collection of strings (file and
directory names I want to watch) into the minifilter, but that seems kind of
evil, given that the list could potentially be very large.

I’ve also pondered sending the filename to UM on a PostCreate, so the UM can
decide whether I want to care about it anymore, and if I do, put a context
on the FO and only record stuff with the context present. If I went this
way, would I use the Stream Context, or Stream Handle Context? I’m
developing for pre-Vista OS versions, so I can’t use a File Context.

Is there a better pattern I haven’t mentioned?

Thanks

Phil

Philip D. Barila (303) 776-1264

2

As far as I can tell Procmon captures everything and then applies user mode
filters.

The PostCreate query would be a good idea but whether you use a
StreamContext or a StreamHandleContext depends on the type of operations you
want to capture. If you only care about operations performed on one handle,
then the streamhandle context is the way to go. Though even in this case you
might still see IO on that FILE_OBJECT if some system component (like the
cache manager) decides to use it to access the data.

Does this help ?

Thanks,

Alex.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, February 03, 2011 11:59 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Pattern for a Selective activity monitor

I’m working on an activity monitor minifilter that started as minispy.
Currently I’m just catching everything, throwing it in the queue for
processing in the UM client, and then in UM, deciding whether I want to
report any specific event. That can be a significant amount of overhead
processing that I’m throwing away because I’m not interested in it,
depending on what I care about, and where the activity is. I’m wondering if
there is a better pattern than this?

I’ve pondered the option of sending a collection of strings (file and
directory names I want to watch) into the minifilter, but that seems kind of
evil, given that the list could potentially be very large.

I’ve also pondered sending the filename to UM on a PostCreate, so the UM can
decide whether I want to care about it anymore, and if I do, put a context
on the FO and only record stuff with the context present. If I went this
way, would I use the Stream Context, or Stream Handle Context? I’m
developing for pre-Vista OS versions, so I can’t use a File Context.

Is there a better pattern I haven’t mentioned?

Thanks

Phil

Philip D. Barila (303) 776-1264

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Alex,

Thanks for the confirmation.

I’m going to respond to this thread again, but I’m currently working on
integration, and can’t do the science experiments that I’d like to do. I
can say that the performance issue that I saw that was causing me to
question the “capture everything” approach was due to running with verifier
on. When I disabled verifier and ran the performance tests, the overhead
was minimal.

Thanks,

Phil

Philip D. Barila (303) 776-1264

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Carp
Sent: Thursday, February 03, 2011 2:38 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Pattern for a Selective activity monitor

As far as I can tell Procmon captures everything and then applies user mode
filters.

The PostCreate query would be a good idea but whether you use a
StreamContext or a StreamHandleContext depends on the type of operations you
want to capture. If you only care about operations performed on one handle,
then the streamhandle context is the way to go. Though even in this case you
might still see IO on that FILE_OBJECT if some system component (like the
cache manager) decides to use it to access the data.

Does this help ?

Thanks,

Alex.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, February 03, 2011 11:59 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Pattern for a Selective activity monitor

I’m working on an activity monitor minifilter that started as minispy.
Currently I’m just catching everything, throwing it in the queue for
processing in the UM client, and then in UM, deciding whether I want to
report any specific event. That can be a significant amount of overhead
processing that I’m throwing away because I’m not interested in it,
depending on what I care about, and where the activity is. I’m wondering if
there is a better pattern than this?

I’ve pondered the option of sending a collection of strings (file and
directory names I want to watch) into the minifilter, but that seems kind of
evil, given that the list could potentially be very large.

I’ve also pondered sending the filename to UM on a PostCreate, so the UM can
decide whether I want to care about it anymore, and if I do, put a context
on the FO and only record stuff with the context present. If I went this
way, would I use the Stream Context, or Stream Handle Context? I’m
developing for pre-Vista OS versions, so I can’t use a File Context.

Is there a better pattern I haven’t mentioned?

Thanks

Phil

Philip D. Barila (303) 776-1264

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer