Hello All,
Is there any way to track the IRPs passing through the file system Mini filter driver? I know there is a tool called IrpTracker. but i think it is not use full for FS mini filter drivers. My mini filter driver does not create a CDO. how can i track the IRPs that are passing through my filter driver?
–Venu
Alex,
With procmon, how can you see the IRPs that are passed to a particular mini filter driver? I see the IRPs on a particular file and the process associated with it. what filters have you applied to see the IRPs coming to a driver? any suggestions would be helpful
–Venu
Well, all IRPs that make it to the minifilter are shown to the minifilter.
You might want to change ProcMon’s minifilter altitude so that it’s right
above your minifilters, but I’ve very rarely needed to do that.
What are you trying to do ?
Thanks,
Alex.
i am trying to find out which windows user mode APIs are responsible for invoking IRPs. in procmon we can’t see the minifilter driver on the screen right? I observed the process name and the IRPs it issued and the files and directories it touched. how can we see the filter drivers name in the procmon? Between, when can a FAST_IO be generated from a user space?
–Venu
>how can we see the filter drivers name in the procmon?
Sorry, I don’t understand the question. Process Monitor implements its file
monitoring with a mini-filter. So, the activity that you see in the output
is the activity that the filter sees.
when can a FAST_IO be generated from a user space?
See here for more about Fast I/O:
http://www.osronline.com/article.cfm?id=166
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
i am trying to find out which windows user mode APIs are responsible for
invoking IRPs. in procmon we can’t see the minifilter driver on the screen
right? I observed the process name and the IRPs it issued and the files and
directories it touched. how can we see the filter drivers name in the
procmon? Between, when can a FAST_IO be generated from a user space?
–Venu
Hi Scott,
I think as Alex said, i need to change the altitude of the procmon just above my filter driver.
by the way is there a way to simulate FAST_IO from user space?
–Venu
AFAIK FastIo will get generated if possible, irrespective of whether the
original call comes from user mode or kernel mode. For example for
FastIoRead, NtReadFile will try to use the FastIo path (thus calling the
FastIoRead) for any call to NtReadFile, regardless of whether it is in
response to a kernel mode call or a user mode call to ReadFile(). However,
in order for FastIoRead to be issued there are some things that need to
align just right (must be a synchronous handle, the file must have been
opened for cached IO and so on). Also, FastIo can be blocked by any filter
in the stack so a filter might not see it just because some other filter
above it couldn’t process it. And finally, in a minifilter, FastIoRead will
be processed through the regular IRP_MJ_READ handler, the only difference
between the FastIo and the IRP path being the flags set
(FLTFL_CALLBACK_DATA_FAST_IO_OPERATION vs.
FLTFL_CALLBACK_DATA_IRP_OPERATION), which might make it seem like the
minifilter is not getting the FastIoRead operation.
ProcMon doesn’t show you how IO operations flow between each filter driver.
It only shows all the requests it sees. I’ve had to always try to deduce
what happens between filters by looking at ProcMon output. When I was
interested in the specific interaction between two filters I sometimes took
different traces, some with ProcMon loaded between them and some with
ProcMon loaded either above or below them (depending on what I was trying to
figure out).
Could you please clarify what you mean when you say you are " trying to find
out which windows user mode APIs are responsible for invoking IRPs "? The
reason I’m asking is that a very large number of APIs in user mode can
result in IRPs being sent. For example, for IRP_MJ_READ you have ReadFile(),
but an IRP_MJ_READ might be issued if any other user mode API happens to
touch memory that is currently paged out. So even printf() might generate an
IRP_MJ_READ…
Thanks,
Alex.
any fast io which can change the file
Hi Alex,
Thank you for your explaination. Yes, i understand that many user mode APIs can cause to generate IRPs. what i would like to know is the user mode apis at the lowest level in the user mode after which the control will be handed over to Kernel mode.
for example: CreateFile, after createFile, the control goes to NT -> Kernel(Zw)
i would like to tap the lowest user mode API’s which will be responsible for generating the IRPs so that i could develop some application which will make use of the lowest level API’s in user mode and generate the IRPs in the kernel level.
That is the reason i am also looking for the user mode api’s which generate Fast I/O in kernel.
any suggestions would be helpfull.
Thanks,
Venu
I would start looking at the Nt apis. See the page about Calling Internal
APIs (http://msdn.microsoft.com/en-us/library/bb432200(v=vs.85).aspx) and
then the page for NtCreateFile
(http://msdn.microsoft.com/en-us/library/bb432380(v=vs.85).aspx) .
I don’t understand your question about fastIO from user mode. In my previous
post I explained that fastIOs are send when the IO manager can, not as a
result of some special call. So even a read from user mode will result in a
FastIoRead when possible. And the same goes for the other FastIos, as far as
I know.
Thanks,
Alex.