>Many things I’ve read indicate that the thread, and I assume therefore the
value in Irp->Tail.Overlay.Thread, would match the thread of >the usermode
program that issued the call, at least for the above two calls
In the case where there are no filters above your filter, this is 100%
accurate for these two calls.
But I’ve read (I don’t remember where) that in a non-top-level filter
driver the thread could be an arbitrary thread in cases where a higher
>level doesn’t pass the IRP directly down (like queuing it).
When there are no filters above you, you are called directly by the I/O
manager as a result of the user requests. This means that you get defined
behavior in your dispatch entry point: you are called in the context of the
requesting thread (and thus process) and the thread field of the IRP matches
the current thread.
However, when there is another filter above you there is someone between you
and the I/O manager, which means they can change the behavior in subtle
ways. This is not to say that it’s common or recommended (see the thread
“SID of requesting thread” from earlier this week), but it’s possible. For
example, a filter may rely on the fact that most drivers don’t care that the
request arrives in the context of the requesting thread, just that it
arrives in the context of the requesting process (see KeStackAttachProcess
for how you can get back to a particular process context). This would allow
that filter to post the operation to a worker thread and send it down later
from a different thread but in the same process context. It’s a bit fast and
loose, but the file system filter world is a crazy place…
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
Hope to see you at the next OSR kernel debugging class February 14th in
Columbia, MD!
wrote in message news:xxxxx@ntfsd…
In a filter driver, I’m trying to reliably determine the thread that
originally caused/created an IRP. Why? Because I want to see if the thread
(in a usermode program) that issues DeviceIoControl is the same thread that
issued the CreateFile on the device. But mostly because I’m trying to
understand thread context in drivers.
Many things I’ve read indicate that the thread, and I assume therefore the
value in Irp->Tail.Overlay.Thread, would match the thread of the usermode
program that issued the call, at least for the above two calls. But I’ve
read (I don’t remember where) that in a non-top-level filter driver the
thread could be an arbitrary thread in cases where a higher level doesn’t
pass the IRP directly down (like queuing it).
The article at
http://msdn.microsoft.com/en-us/library/ff540124(v=VS.85).aspx specifies
“thread context requirements” for the dispatch routines. It makes be believe
that the value in Irp->Tail.Overlay.Thread is in the usermode program
(again, for the above two calls) regardless of where my driver is in the
stack.
The documentation for IoGetRequestorProcess gives me similar worries (so I
assume gets EPROCESS from the ETHREAD pointer somehow)
I’d like to believe the MSDN article. Can anyone add any insight to this?
Mike