Thank you for your quick response Jamey.
If I may, I would like to ask for some clarification on a few points that
are troubling me. The OSR article I mentioned in my original post has a
few rules that seem to indicate the code might be wrong. For instance
(from the article):
“Rule 1: If you complete the IRP passed to your Dispatch Routine in your
Dispatch Routine, you must (a) Fill the IRP’s completion status and
information into the IRP’s I/O status block, (b) Call IoCompleteRequest(),
and (c) return the status you used to complete the IRP (the status value
you filled into the .Status member of the I/O status block in the IRP) as
the return value from your Dispatch Routine.”
I see in my original post I did not emphasize the fact that the filter
layered above us was actually completing the IRP from their dispatch
routine. Please forgive this oversight. In the filter layered above us,
after their completion routine resynchs back to the dispatch routine, the
IRP is being completed with STATUS_SUCCESS inside of Irp->IoStatus.Status,
but the dispatch routine is returning STATUS_PENDING. That seems to be a
clear violation of the rule. Continuing from the article:
“Rule 2: If you return from your Dispatch Routine without completing the
IRP passed to you, you must (a) Mark the IRP pending, before the IRP is
completed to your caller, by calling IoMarkIrpPending(), and (b) return
STATUS_PENDING from your Dispatch Routine.”
The rule seems to indicate that if you don’t complete the IRP, you should
mark it pending. In the completion routine, the IRP is marked pending.
However, when the completion routine resynchs back to dispatch, the IRP is
completed. If I read the rule correctly, since the IRP was completed in
dispatch, there was no need to mark it pending. Which leads me to wonder
if this causes any timing issues or confusion in the IoManager.
In fairness, I believe I should include this third rule from the article.
I believe this may have been the original intention of the filter layered
above us:
“Rule 3: If you return the status from the driver below yours as the
status from your dispatch routine, the IRP’s pending status, as indicated
by Irp->PendingReturned, must be propagated with a completion routine.”
However, since they are resynching back to dispatch and completing the
IRP, this rule does not seem to apply (by way of Rule 1… or perhaps I’m
wrong about that).
If you can help clear up these details for me, I would appreciate it. If,
however, this indicates an error in the filter, I would ask if such errors
could potentially lead to a stop code 0x44.
Thank you,
M.G.
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, August 18, 2003 1:47 PM
To: File Systems Developers
Subject: [ntfsd] RE: STATUS_PENDING down Create path
The code in question looks good.
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M.G.
Sent: Monday, August 18, 2003 11:08 AM
To: File Systems Developers
Subject: [ntfsd] STATUS_PENDING down Create path
This post contains two questions, but first, here is the background info.
While developing a file system filter, I decided to run some interop tests
with major third party vendors. I installed one third party
application/filter and began to receive numerous stop code 0x44’s (all of
which have been down the create path). I had not received this error
while testing against similar third party filters, so I began
disassembling their dispatch and completion routines for the create path.
From this, I have been able to determine that their completion routine is
very simple, but appears to have a mistake in it. I’ve converted the
assembly into C to make it easier to follow:
NTSTATUS
IoCompletion(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{
// My filter, which is layered below theirs, will return
// STATUS_PENDING down create dispatch, so this if block
// will execute.
//
if(Irp->PendingReturned)
{
// This is what leads to my first question. Is it
// “wrong” to mark the irp pending and yet still
// return STATUS_MORE_PROCESSING_REQUIRED? This OSR
// article appears to imply it might:
// http://www.osronline.com/article.cfm?id=21
//
IoMarkIrpPending(Irp);
}
// Context is an event used to resynch completion
// back to dispatch
//
KeSetEvent(Context);
return STATUS_MORE_PROCESSING_REQUIRED
}
Once the completion routine was executed, I had a break point set in the
dispatch routine at the point where execution would continue when the
event that was passed in as Context was set. Of course, it is common to
resynch completion back to dispatch in this manner, but at the end, their
dispatch returns STATUS_PENDING. It would seem that at this point, the
filter would want to return the status contained in the irp (which was
STATUS_SUCCESS on the create) instead of propagating the STATUS_PENDING.
Is this a valid thing to do (my opinion is that it doesn’t look right)?
With this information in mind, would it be reasonable to conclude that
this is the actual bug (in their filter) which is causing my stop code
0x44’s?
Thank you,
M.G.
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to xxxxx@lists.osr.com