In a filter driver, looking at the data available to me in a completion routine (I’m peeking at the data returned from IRP_MJ_DIRECTORY_CONTROL if it matters), I see MdlAddress = AssociatedIrp.SystemBuffer = NULL and UserBuffer != NULL. (That means the caller must be doing “neither I/O”, right?) I’ve read that the UserBuffer pointer may not be valid in the currently running process and that makes sense.
So how do I get the right pointer for the data returned in the completion routine? Can I update the MdlAddress in the dispatch routine and access it in the completion routine?
My guess would be something like:
(in the dispatch routine)
if(Irp->MdlAddress==NULL) {
Irp->MdlAddress = IoAllocateMdl(Irp->UserBuffer,…)
MmProbeAndLockPages(Irp->MdlAddress) /* surrounded by try/except */
}
(in the completion routine)
pointer_i_can_use = MmGetSystemAddressForMdlSafe(Irp->MdlAddress,…)
if(i_set_the_mdl_address) {
MmUnlockPages(Irp->MdlAddress)
Irp->MdlAddress = NULL
}
How can I track if i set the mdl address in the dispatch routine?
Thanks
> (I’m peeking at the data returned from IRP_MJ_DIRECTORY_CONTROL if it
matters
It does if you are looking at IRP_MN_QUERY_DIRECTORY. It appears that this
some times uses a compound neither IO/Buffered IO. This means that on the
way down the user buffer is valid, but on the way back
AssociatedIrp.SystemBuffer is set. In some cases AssociatedIrp.SystemBuffer
is set before and afterwards and in some cases AssociatedIrp.SystemBuffer is
null before afterwards.
My assumption is that the IO manager spots AssociatedIrp.SystemBuffer !=
null on the way back down and is fooled into thinking that the request was
buffered.
Otherwise your code looks OK.
How can I track if i set the mdl address in the dispatch routine?
AFAIK in modern releases you don’t need to and the IoManager will do the
tear down. But if in doubt you could always not use the MdlAddress and just
pass the MDL over as a parameter.
wrote in message news:xxxxx@ntfsd…
In a filter driver, looking at the data available to me in a completion
routine (I’m peeking at the data returned from IRP_MJ_DIRECTORY_CONTROL if
it matters), I see MdlAddress = AssociatedIrp.SystemBuffer = NULL and
UserBuffer != NULL. (That means the caller must be doing “neither I/O”,
right?) I’ve read that the UserBuffer pointer may not be valid in the
currently running process and that makes sense.
So how do I get the right pointer for the data returned in the completion
routine? Can I update the MdlAddress in the dispatch routine and access it
in the completion routine?
My guess would be something like:
(in the dispatch routine)
if(Irp->MdlAddress==NULL) {
Irp->MdlAddress = IoAllocateMdl(Irp->UserBuffer,…)
MmProbeAndLockPages(Irp->MdlAddress) /* surrounded by try/except */
}
(in the completion routine)
pointer_i_can_use = MmGetSystemAddressForMdlSafe(Irp->MdlAddress,…)
if(i_set_the_mdl_address) {
MmUnlockPages(Irp->MdlAddress)
Irp->MdlAddress = NULL
}
How can I track if i set the mdl address in the dispatch routine?
Thanks
Given the same scenario (only UserBuffer != null in the dispatch routine), how do you get the right pointer in the dispatch routine when my driver is not the top-level driver? KeStackAttachProcess(IoGetRequestorProcess(Irp))?
>Given the same scenario (only UserBuffer != null in the dispatch routine),
how do you get the right pointer in the dispatch routine when >my driver is
not the top-level driver? KeStackAttachProcess(IoGetRequestorProcess(Irp))?
Even if you’re not the top filter device, you’re still filtering a highest
level driver. Highest level drivers have an assumption that they’re called
in the context of the requesting process, so filter drivers above you can’t
break this contract (if they could, all file systems would have to do what
you’re suggesting above).
So, this is a non-issue. If all you have is a user buffer in the IRP then
(presumably) that buffer is valid for the current process context. You do
have to abide by all of the usual METHOD_NEITHER processing rules though
(__try/__except, probe, etc).
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
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!