The debugger caught the following error:
*** Assertion Failed : !irp->PendingReturned
*** Source File : D:\nt\private\ntos\io\parse.c, line 1236
Is the source to this module available? Is there a list explaining what
these errors might mean?
Ralph Shnelvar
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You issued an IoMarkIrpPending() on the IRP but failed to return
STATUS_PENDING: this is a CREATE irp, so I’m
guessing you just did IoMarkIrpPending() on the IRP, but then went ahead
and called the file system
anyways & returned the status of IoCallDriver() from your create
dispatch.
Ravi
-----Original Message-----
From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
Sent: Friday, November 16, 2001 11:53 AM
To: File Systems Developers
Subject: [ntfsd] parse.c
The debugger caught the following error:
*** Assertion Failed : !irp->PendingReturned
*** Source File : D:\nt\private\ntos\io\parse.c, line 1236
Is the source to this module available? Is there a list explaining what
these errors might mean?
Ralph Shnelvar
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Dear Ravisankar Pudipeddi:
On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
Sigh. I have so many questions.
You issued an IoMarkIrpPending() on the IRP
Correct.
but failed to return
STATUS_PENDING:
Failed to return it from where? The completion routine? THe dispatch
routine?
this is a CREATE irp,
I’m guessing you know that because you have access to the source code. Is
there any other way to know that?
so I’m
guessing you just did IoMarkIrpPending() on the IRP, but then went ahead
and called the file system
anyways & returned the status of IoCallDriver() from your create
dispatch.
I’m not sure.
The sequence of events is roughly what Nagar outlines:
0) A completion routine is set up to be called on failure.
Now I do stuff that Nagar doesn’t talk about
So where did I go wrong? 
BTW, is there a routine to unmark the Irp as pending?
Ravi
Ralph Shnelvar
-----Original Message-----
From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
Sent: Friday, November 16, 2001 11:53 AM
To: File Systems Developers
Subject: [ntfsd] parse.cThe debugger caught the following error:
*** Assertion Failed : !irp->PendingReturned
*** Source File : D:\nt\private\ntos\io\parse.c, line 1236Is the source to this module available? Is there a list explaining what
these errors might mean?Ralph Shnelvar
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@dos32.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
1.) STATUS_PENDING is not a valid status to return from a completion
routine, so I meant the dispatch.
2.) You can tell what the IRP is by pressing ‘b’ and looking at it via
!irp in the debugger.
3.) From your description it appears you are synchronizing the IRP in
your create dispatch - i.e. you signalled an event from your completion
routine & picked up processing in your dispatch (point number 4. where
you are touching the IRP after calling IoCallDriver(). Not safe unless
you aborted completion in your completion routine)
4.) I fail to understand point number 0) where you claim to set a
completion routine only on failure. That wouldn’t work, as it is not
possible to safely determine whether you can touch the IRP or not in
your dispatch.
5.) In any case - since you synchronize the IRP - don’t mark the IRP
pending to begin with.
6.) You can avoid all this mess if you just return status of
IoCallDriver() from your dispatch and modify Irp->IoStatus.Status
appropriately in your completion on create failure. Since you are
trapping only failure, you wouldn’t need to cancel the open & you can do
this at DISPATCH_LEVEL.
7.) No there isn’t an IoUnmarkIrpPending(). Believe me, this gets asked
a lot.
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.
-----Original Message-----
From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
Sent: Friday, November 16, 2001 1:11 PM
To: File Systems Developers
Subject: [ntfsd] RE: parse.c
Dear Ravisankar Pudipeddi:
On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
Sigh. I have so many questions.
You issued an IoMarkIrpPending() on the IRP
Correct.
but failed to return
STATUS_PENDING:
Failed to return it from where? The completion routine? THe dispatch
routine?
this is a CREATE irp,
I’m guessing you know that because you have access to the source code.
Is there any other way to know that?
so I’m
guessing you just did IoMarkIrpPending() on the IRP, but then went
ahead
and called the file system
anyways & returned the status of IoCallDriver() from your create
dispatch.
I’m not sure.
The sequence of events is roughly what Nagar outlines:
0) A completion routine is set up to be called on failure.
Now I do stuff that Nagar doesn’t talk about
So where did I go wrong?
BTW, is there a routine to unmark the Irp as pending?
Ravi
Ralph Shnelvar
-----Original Message-----
From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
Sent: Friday, November 16, 2001 11:53 AM
To: File Systems Developers
Subject: [ntfsd] parse.cThe debugger caught the following error:
*** Assertion Failed : !irp->PendingReturned
*** Source File : D:\nt\private\ntos\io\parse.c, line 1236Is the source to this module available? Is there a list explaining
what these errors might mean?Ralph Shnelvar
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@dos32.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Dear “Ravisankar Pudipeddi”
On Fri, 16 Nov 2001 14:52:53 -0800, you wrote:
1.) STATUS_PENDING is not a valid status to return from a completion
routine, so I meant the dispatch.
Of course.
2.) You can tell what the IRP is by pressing ‘b’ and looking at it via
!irp in the debugger.
Grr. I use SoftICE. Anyone know if/how to get this info out of SoftIce.
3.) From your description it appears you are synchronizing the IRP in
your create dispatch - i.e. you signalled an event from your completion
routine & picked up processing in your dispatch (point number 4. where
you are touching the IRP after calling IoCallDriver(). Not safe unless
you aborted completion in your completion routine)
Oops, forgot to say that the completion return
STATUS_MORE_PROCESSING_REQUIRED
4.) I fail to understand point number 0) where you claim to set a
completion routine only on failure.
Sorry. I do a
IoSetCompletionRoutine
(
Irp, // IN PIRP Irp
SfCreateCompletion, // IN PIO_COMPLETION_ROUTINE
0, // IN PVOID Context,
FALSE, // IN BOOLEAN InvokeOnSuccess,
TRUE, // IN BOOLEAN InvokeOnError,
FALSE // IN BOOLEAN InvokeOnCancel
);
Is that clearer?
That wouldn’t work, as it is not
possible to safely determine whether you can touch the IRP or not in
your dispatch.
??? I thought the entire point of STATUS_MORE_PROCESSING_REQUIRED was to
return the Irp back to the dispatch routine.
Or do I need to allocate a new Irp?
5.) In any case - since you synchronize the IRP - don’t mark the IRP
pending to begin with.
I am not explicitly synchronizing the Irp. I am using the technique
explained in Chapter 12 if Rajeev Nagar’s *Windows NT File System Internals*
as I am willing to live with the overhead.
Are you familiar with the technique that Nagar suggests?
6.) You can avoid all this mess if you just return status of
IoCallDriver() from your dispatch and modify Irp->IoStatus.Status
appropriately in your completion on create failure. Since you are
trapping only failure, you wouldn’t need to cancel the open & you can do
this at DISPATCH_LEVEL.
From my poor understanding of the documentation, I am unclear as to what
IRQL the completion routine runs at.
7.) No there isn’t an IoUnmarkIrpPending(). Believe me, this gets asked
a lot.
I’m sure it gets asked a lot.
Assuming it gets asked a lot, why is such functionality not provided? What
in the OS prevents an IRP from being unmarked as pending?
Thanks,
RaviThis posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.
Ralph Shnelvar
-----Original Message-----
From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
Sent: Friday, November 16, 2001 1:11 PM
To: File Systems Developers
Subject: [ntfsd] RE: parse.cDear Ravisankar Pudipeddi:
On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
Sigh. I have so many questions.
>You issued an IoMarkIrpPending() on the IRP
Correct.
>but failed to return
>STATUS_PENDING:Failed to return it from where? The completion routine? THe dispatch
routine?>this is a CREATE irp,
I’m guessing you know that because you have access to the source code.
Is there any other way to know that?> so I’m
>guessing you just did IoMarkIrpPending() on the IRP, but then went
ahead
>and called the file system
>anyways & returned the status of IoCallDriver() from your create
>dispatch.I’m not sure.
The sequence of events is roughly what Nagar outlines:
0) A completion routine is set up to be called on failure.
- IoMarkIrpPending() is called.
- IoCallDriver() is called
- The completion routine does the standard
if (Irp->PendingReturned)
IoMarkIrpPending( Irp );Now I do stuff that Nagar doesn’t talk about
- On return from IoCallDriver() I modify the Irp to point to
a new file name.- I issue IoComplete on the Irp
- I return STATUS_REPARSE from the dispatch routine.
So where did I go wrong?
BTW, is there a routine to unmark the Irp as pending?
>Ravi
Ralph Shnelvar
>
>
>-----Original Message-----
>From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
>Sent: Friday, November 16, 2001 11:53 AM
>To: File Systems Developers
>Subject: [ntfsd] parse.c
>
>
>The debugger caught the following error:
>
>*** Assertion Failed : !irp->PendingReturned
>*** Source File : D:\nt\private\ntos\io\parse.c, line 1236
>
>Is the source to this module available? Is there a list explaining
>what these errors might mean?
>
>Ralph Shnelvar
>
>—
>You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
>To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>—
>You are currently subscribed to ntfsd as: xxxxx@dos32.com
>To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@dos32.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You have not said that you explicitly returned an STATUS_PENDING from
wherever you set the IoMarkPending, probably your dispatch routine. Instead,
you probably did a return on IoCallDriver as your return status. If you are
going to mark an IRP as pending, you need to return a pending status. Your
understanding of the required sequence of events seems to be flawed in this
case.
Why exactly are you setting the IRP to be pending when you are going to be
calling IoCallDriver immediately after? (See your step 2).
Will
----- Original Message -----
From: “Ralph Shnelvar”
To: “File Systems Developers”
Sent: Friday, November 16, 2001 9:10 PM
Subject: [ntfsd] RE: parse.c
> Dear Ravisankar Pudipeddi:
>
> On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
>
> Sigh. I have so many questions.
>
> >You issued an IoMarkIrpPending() on the IRP
>
> Correct.
>
> >but failed to return
> >STATUS_PENDING:
>
> Failed to return it from where? The completion routine? THe dispatch
> routine?
>
> >this is a CREATE irp,
>
> I’m guessing you know that because you have access to the source code. Is
> there any other way to know that?
>
> > so I’m
> >guessing you just did IoMarkIrpPending() on the IRP, but then went ahead
> >and called the file system
> >anyways & returned the status of IoCallDriver() from your create
> >dispatch.
>
> I’m not sure.
>
> The sequence of events is roughly what Nagar outlines:
> 0) A completion routine is set up to be called on failure.
> 1) IoMarkIrpPending() is called.
> 2) IoCallDriver() is called
> 3) The completion routine does the standard
> if (Irp->PendingReturned)
> IoMarkIrpPending( Irp );
>
> Now I do stuff that Nagar doesn’t talk about
>
> 4) On return from IoCallDriver() I modify the Irp to point to
> a new file name.
> 5) I issue IoComplete on the Irp
> 6) I return STATUS_REPARSE from the dispatch routine.
>
> So where did I go wrong?
>
> BTW, is there a routine to unmark the Irp as pending?
>
> >Ravi
>
> Ralph Shnelvar
>
> >
> >
> >-----Original Message-----
> >From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
> >Sent: Friday, November 16, 2001 11:53 AM
> >To: File Systems Developers
> >Subject: [ntfsd] parse.c
> >
> >
> >The debugger caught the following error:
> >
> > Assertion Failed : !irp->PendingReturned
> > Source File : D:\nt\private\ntos\io\parse.c, line 1236
> >
> >Is the source to this module available? Is there a list explaining what
> >these errors might mean?
> >
> >Ralph Shnelvar
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@dos32.com
> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Dear Will:
On Mon, 19 Nov 2001 10:04:00 -0000, you wrote:
[snip]
Why exactly are you setting the IRP to be pending when you are going to be
calling IoCallDriver immediately after? (See your step 2).
Because that is what Nagar does on page 661 in his book *File System
Internals*.
According to Nagar, this is supposed to simplify completion procession at
the expense of a little CPU time.
Will
Ralph
----- Original Message -----
From: “Ralph Shnelvar”
>To: “File Systems Developers”
>Sent: Friday, November 16, 2001 9:10 PM
>Subject: [ntfsd] RE: parse.c
>
>
>> Dear Ravisankar Pudipeddi:
>>
>> On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
>>
>> Sigh. I have so many questions.
>>
>> >You issued an IoMarkIrpPending() on the IRP
>>
>> Correct.
>>
>> >but failed to return
>> >STATUS_PENDING:
>>
>> Failed to return it from where? The completion routine? THe dispatch
>> routine?
>>
>> >this is a CREATE irp,
>>
>> I’m guessing you know that because you have access to the source code. Is
>> there any other way to know that?
>>
>> > so I’m
>> >guessing you just did IoMarkIrpPending() on the IRP, but then went ahead
>> >and called the file system
>> >anyways & returned the status of IoCallDriver() from your create
>> >dispatch.
>>
>> I’m not sure.
>>
>> The sequence of events is roughly what Nagar outlines:
>> 0) A completion routine is set up to be called on failure.
>> 1) IoMarkIrpPending() is called.
>> 2) IoCallDriver() is called
>> 3) The completion routine does the standard
>> if (Irp->PendingReturned)
>> IoMarkIrpPending( Irp );
>>
>> Now I do stuff that Nagar doesn’t talk about
>>
>> 4) On return from IoCallDriver() I modify the Irp to point to
>> a new file name.
>> 5) I issue IoComplete on the Irp
>> 6) I return STATUS_REPARSE from the dispatch routine.
>>
>> So where did I go wrong?
>>
>> BTW, is there a routine to unmark the Irp as pending?
>>
>> >Ravi
>>
>> Ralph Shnelvar
>>
>> >
>> >
>> >-----Original Message-----
>> >From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
>> >Sent: Friday, November 16, 2001 11:53 AM
>> >To: File Systems Developers
>> >Subject: [ntfsd] parse.c
>> >
>> >
>> >The debugger caught the following error:
>> >
>> > Assertion Failed : !irp->PendingReturned
>> > Source File : D:\nt\private\ntos\io\parse.c, line 1236
>> >
>> >Is the source to this module available? Is there a list explaining what
>> >these errors might mean?
>> >
>> >Ralph Shnelvar
>> >
>> >—
>> >You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
>> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>> >
>> >—
>> >You are currently subscribed to ntfsd as: xxxxx@dos32.com
>> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>>
>> —
>> You are currently subscribed to ntfsd as: xxxxx@javabear.com
>> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@dos32.com
>To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Ralph:
The example referred to the book shows that the code ALWAYS returns
STATUS_PENDING. That is not indicated in your logic. So the answer to your
question stands, return STATUS_PENDING in the function where you set the IRP
to pending. This is also stated in the bullet list in the preceding
paragraph.
I’m not quite sure your modifications warrant the need to follow the
example code as written, since all you essentially need to do is return
whatever is returned from IoCallDriver and not mark the IO as pending. Are
you doing asynchronous communication to the underlying FSD? I don’t really
buy the fact that doing this actually simplifies coding the completion of
the IRP at all.
Will
----- Original Message -----
From: “Ralph Shnelvar”
To: “File Systems Developers”
Sent: Monday, November 19, 2001 11:59 PM
Subject: [ntfsd] RE: parse.c
> Dear Will:
>
> On Mon, 19 Nov 2001 10:04:00 -0000, you wrote:
>
> [snip]
>
> >Why exactly are you setting the IRP to be pending when you are going to
be
> >calling IoCallDriver immediately after? (See your step 2).
>
> Because that is what Nagar does on page 661 in his book File System
> Internals.
>
> According to Nagar, this is supposed to simplify completion procession at
> the expense of a little CPU time.
>
> >
> >
> >Will
>
> Ralph
>
>
> >
> >----- Original Message -----
> >From: “Ralph Shnelvar”
> >To: “File Systems Developers”
> >Sent: Friday, November 16, 2001 9:10 PM
> >Subject: [ntfsd] RE: parse.c
> >
> >
> >> Dear Ravisankar Pudipeddi:
> >>
> >> On Fri, 16 Nov 2001 12:10:08 -0800, you wrote:
> >>
> >> Sigh. I have so many questions.
> >>
> >> >You issued an IoMarkIrpPending() on the IRP
> >>
> >> Correct.
> >>
> >> >but failed to return
> >> >STATUS_PENDING:
> >>
> >> Failed to return it from where? The completion routine? THe dispatch
> >> routine?
> >>
> >> >this is a CREATE irp,
> >>
> >> I’m guessing you know that because you have access to the source code.
Is
> >> there any other way to know that?
> >>
> >> > so I’m
> >> >guessing you just did IoMarkIrpPending() on the IRP, but then went
ahead
> >> >and called the file system
> >> >anyways & returned the status of IoCallDriver() from your create
> >> >dispatch.
> >>
> >> I’m not sure.
> >>
> >> The sequence of events is roughly what Nagar outlines:
> >> 0) A completion routine is set up to be called on failure.
> >> 1) IoMarkIrpPending() is called.
> >> 2) IoCallDriver() is called
> >> 3) The completion routine does the standard
> >> if (Irp->PendingReturned)
> >> IoMarkIrpPending( Irp );
> >>
> >> Now I do stuff that Nagar doesn’t talk about
> >>
> >> 4) On return from IoCallDriver() I modify the Irp to point to
> >> a new file name.
> >> 5) I issue IoComplete on the Irp
> >> 6) I return STATUS_REPARSE from the dispatch routine.
> >>
> >> So where did I go wrong?
> >>
> >> BTW, is there a routine to unmark the Irp as pending?
> >>
> >> >Ravi
> >>
> >> Ralph Shnelvar
> >>
> >> >
> >> >
> >> >-----Original Message-----
> >> >From: Ralph Shnelvar [mailto:xxxxx@dos32.com]
> >> >Sent: Friday, November 16, 2001 11:53 AM
> >> >To: File Systems Developers
> >> >Subject: [ntfsd] parse.c
> >> >
> >> >
> >> >The debugger caught the following error:
> >> >
> >> > Assertion Failed : !irp->PendingReturned
> >> > Source File : D:\nt\private\ntos\io\parse.c, line 1236
> >> >
> >> >Is the source to this module available? Is there a list explaining
what
> >> >these errors might mean?
> >> >
> >> >Ralph Shnelvar
> >> >
> >> >—
> >> >You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
> >> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >> >
> >> >—
> >> >You are currently subscribed to ntfsd as: xxxxx@dos32.com
> >> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >>
> >>
> >> —
> >> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> >> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@dos32.com
> >To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Dear Will:
On Mon, 19 Nov 2001 16:41:44 -0000, you wrote:
Ralph:
The example referred to the book shows that the code ALWAYS returns
STATUS_PENDING.
Oh!
That is not indicated in your logic.
Correct. It was not.
So the answer to your
question stands, return STATUS_PENDING in the function where you set the IRP
to pending. This is also stated in the bullet list in the preceding
paragraph.
Ah. Damn, now Nagar’s English becomes clear. My fault; not his.
I’m not quite sure your modifications warrant the need to follow the
example code as written, since all you essentially need to do is return
whatever is returned from IoCallDriver and not mark the IO as pending. Are
you doing asynchronous communication to the underlying FSD? I don’t really
buy the fact that doing this actually simplifies coding the completion of
the IRP at all.
I’m glad you’re not buying it because I’m doing a damned bad job of selling
it.
Frankly, I still don’t “get it.” I don’t get how the wdm/Irp model works
for FSDs. I’ve hit the books
Nagar: File System Internals
Oney: Windows Driver Model
everything I can get my hands on from OSR
everything I can get my hands on from Sysinternals
and I still don’t “get it.”
Are there other references for the feeble minded?
So for me and other newbies, how about answering some VERY basic questions.
Does a call to IoCallDriver() always return?
If IoCallDriver() always returns, under what circumstances can I be
guaranteed that the Irp is still available for modification? Is it legal
for a lower level driver to free the Irp?
If a completion routine returns STATUS_MORE_PROCESSING_REQUIRED, what
status code is returned from IoCallDriver() and where does that status code
come from?
MJ_CREATE Irps are by definition synchronous (I think). Does it ever
make sense to mark such an Irp as pending?
Will
Ralph Shnelvar
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hello, below is the summary of my experience… Don’t take it as the holy
truth.
I will be glad to ear comments from more knowledgeable people …
So for me and other newbies, how about answering some VERY basic
questions.
- Does a call to IoCallDriver() always return?
Yes. Unless the system deadlocks or crash, that is …
- If IoCallDriver() always returns, under what circumstances can I be
guaranteed that the Irp is still available for modification? Is it legal
for a lower level driver to free the Irp?
The IRP is available if something else than STATUS_PENDING is returned by
IoCallDriver.
If STATUS_PENDING is returned from IoCallDriver, the Irp may be freed by a
completion routine.
If you set a completion routine at your level, you may not be called if a
lower layer returned STATUS_MORE_PROCESSING_REQUIRED.
If YOU return STATUS_MORE_PROCESSING_REQUIRED, the completion processing
stops and it is YOUR
responsibility to free the IRP.
- If a completion routine returns STATUS_MORE_PROCESSING_REQUIRED, what
status code is returned from IoCallDriver() and where does that status
code
come from?
The status code returned by IoCallDriver is either :
STATUS_PENDING if the Irp is not completed (IoCompleteRequest called by
all iocompletion routines) before IoCallDriver returns
the status stored in the IRP IoStatus block, if the IRP is completed.
- MJ_CREATE Irps are by definition synchronous (I think). Does it ever
make sense to mark such an Irp as pending?
Joker for this one. I remember that I read somewhere this has a special
meaning for the IoManager, but this is unclear
for me.
Hope this helps, and that most of it is right …
Regards,
Pascal Dameme.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> 1) Does a call to IoCallDriver() always return?
Yes. Its just a function call, no magic.
- If IoCallDriver() always returns, under what circumstances
can I be guaranteed that the Irp is still available for
modification? Is it legal for a lower level driver to free
the Irp?
Think of the IRP as a token being passed around. Whoever has it is “it”
and is responsible for making the operation go forward. When you are
“it”, you can do whatever you want with it (within reason, an
occasionally complex topic). When you are not “it” you should be doing
absolutely nothing with respect to the operation, not to mention
modifying the IRP.
You become it when
and by extension of 2, when a completion routine of yours is called and
you return STATUS_MORE_PROCESSING_REQUIRED, you are still “it”. A common
way of bopping back to a non-completion routine context (remember these
can happen at DPC level) is to schedule a workitem or have had your
major entry point call wait on an event which your completion routine
will trigger. Look at the IFS Kit “samples” (the real FAT and CD
filesystems) at how they, for instance, handle the MultiSync IO path
where they are launching multiple IRPs to cover an IO range which is
split across multiple disk extents of a file. If the IO is synchronous
its doing exactly that event trick to re-synchronize after the
completion of the IO.
When you are not “it”, you cannot safely modify the IRP. Even if you
know your completion routine *will* return
STATUS_MORE_PROCESSING_REQUIRED you have to know that that has happened,
otherwise you could be modifying the IRP while someone else is “it”, and
that’s very bad juju. Even worse is when your completion routine won’t
return SMPR, because the next instruction you execute after IoCallDriver
may occur *after* the operation has completed, at which point the IRP
has been freed.
- If a completion routine returns STATUS_MORE_PROCESSING_REQUIRED,
what status code is returned from IoCallDriver() and where does
that status code come from?
Apples and oranges.
IoCallDriver is only an indirect way of referencing through the lower
drivers major entry point table to call a function in that driver. Its
doing the same thing you do. At the very very bottom of the call stack,
someone will return a status. This will probably be what you get. Either
it’ll be PENDING, in which case we’re basically saying that the IO is
not completing now (and if you want to know what it’ll complete with,
hook back up with it in your completion routine) or it’ll return a
non-PENDING status, in which case the status had best be the same as the
one in the IoStatus block of the IRP. Barring a bug on someone’s part.
(extend that last statement into a rule about what you need to do if you
plan to alter the status after the IRP has begun completing)
STATUS_MORE_PROCESSING_REQUIRED in a completion routine just tells the
IO system that you’ll be responsible for calling IoCompleteRequest again
at some point. You are “it” again. Doing that does not itself alter the
status the IO is completing with.
- MJ_CREATE Irps are by definition synchronous (I think). Does it
ever make sense to mark such an Irp as pending?
Unless you need to, no.
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
----- Original Message -----
From: “Pascal Dameme”
To: “File Systems Developers”
Sent: Tuesday, November 20, 2001 5:34 AM
Subject: [ntfsd] RE: parse.c
> Hello, below is the summary of my experience… Don’t take it as the holy
> truth.
> I will be glad to ear comments from more knowledgeable people …
> >
> > So for me and other newbies, how about answering some VERY basic
> questions.
> >
> > 1) Does a call to IoCallDriver() always return?
You can basically assume this if you are new to driver development and are
calling trusted lowerver level drivers.
However, if you are developing a stack of drivers, you’ll need to guarentee
this.
> >
> Yes. Unless the system deadlocks or crash, that is …
>
> > 2) If IoCallDriver() always returns, under what circumstances can I be
> > guaranteed that the Irp is still available for modification? Is it
legal
> > for a lower level driver to free the Irp?
> >
>
> The IRP is available if something else than STATUS_PENDING is returned by
> IoCallDriver.
>
> If STATUS_PENDING is returned from IoCallDriver, the Irp may be freed by a
> completion routine.
>
> If you set a completion routine at your level, you may not be called if a
> lower layer returned STATUS_MORE_PROCESSING_REQUIRED.
>
> If YOU return STATUS_MORE_PROCESSING_REQUIRED, the completion processing
> stops and it is YOUR
> responsibility to free the IRP.
Be careful with this one. Make sure you do not mess around with the IRP from
within the calling dispatch routine after you’ve pushed it down the driver
stack. Esssentially that IRP is gone. Post IoCallDriver IRP manipulation can
obviously be done in the completion routine when the response makes its way
back up the driver stack.
Will
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>> 1) Does a call to IoCallDriver() always return?
You can basically assume this if you are new to driver
development and are calling trusted lowerver level drivers.However, if you are developing a stack of drivers, you’ll
need to guarantee this.
What case are you thinking of? It is not legal to throw or fail to catch
exceptions that cross driver boundaries.
–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
----- Original Message -----
From: “Daniel Lovinger”
To: “File Systems Developers”
Sent: Tuesday, November 20, 2001 12:52 PM
Subject: [ntfsd] RE: parse.c
> However, if you are developing a stack of drivers, you’ll
> need to guarantee this.
>What case are you thinking of? It is not legal to throw or fail to catch
>exceptions that cross driver boundaries.
The simplist case, in which you are developing multiple drivers stacked on
top of each other. You obviously need to make sure calls from the top have a
response of some sort.
I don’t even believe what you propose is actually do-able in general code,
much less driver code.
Will
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> The simplest case, in which you are developing multiple
drivers stacked on top of each other. You obviously need
to make sure calls from the top have a response of some sort.
We’re clearly talking about different things.
Ralph’s original question seemed, to me, to be clearly asking about
straight through execution and whether IoCallDriver was guaranteed to
return. Asked and answered: yes.
I am not at all sure what case you are referring to. If you are pointing
at cases where you need to see the final status code, yes, clearly to
handle the asynchronous IRPs you have to do more work. However, assuming
that drivers have to see final status on all operations is unwarranted,
and further assuming that a driver which did need to see final status
would have to serialize execution in the context of its major entry
point or otherwise at the point it passed the IRP down with IoCallDriver
is also unwarranted.
I don’t even believe what you propose is actually do-able
in general code, much less driver code.
I’m not sure you’ve understood what I proposed. If you could clarify
exactly what doesn’t make sense, perhaps I could help.
–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
One Of The Laws Of The IRP Processing:
if( Irp->PendingReturned )
IoMarkIrpPending(Irp);
in it.
The bug you see is possibly due to this.
Max
----- Original Message -----
From: “Ralph Shnelvar”
To: “File Systems Developers”
Sent: Friday, November 16, 2001 10:52 PM
Subject: [ntfsd] parse.c
> The debugger caught the following error:
>
> Assertion Failed : !irp->PendingReturned
> Source File : D:\nt\private\ntos\io\parse.c, line 1236
>
> Is the source to this module available? Is there a list explaining what
> these errors might mean?
>
> Ralph Shnelvar
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Why exactly are you setting the IRP to be pending when you are going to be
calling IoCallDriver immediately after? (See your step 2).
This:
IoMarkIrpPending(Irp);
return IoCallDriver(…, Irp);
The correct way is:
IoMarkIrpPending(Irp);
IoCallDriver(…, Irp);
return STATUS_PENDING;
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> This:
IoMarkIrpPending(Irp);
return IoCallDriver(…, Irp);
That’s not a well know bug. That’s just bad coding.
Will
----- Original Message -----
From: “Maxim S. Shatskih”
To: “File Systems Developers”
Sent: Wednesday, November 21, 2001 7:29 AM
Subject: [ntfsd] RE: parse.c
> > Why exactly are you setting the IRP to be pending when you are going to
be
> > calling IoCallDriver immediately after? (See your step 2).
>
>
> - is a well-known bug, and even some MS’s drivers (like CLASS2 in NT4) had
it. If the lower driver will return something other then
> STATUS_PENDING, then the OS will go mad.
> CLASS2 bug was unnoticed because MS suggested CLASS2 to run on top of
SCSIPORT, and SCSIPORT always returns STATUS_PENDING. Our own
> SCSI port driver sometimes did not this, and we have hit this bug.
>
> The correct way is:
>
> IoMarkIrpPending(Irp);
> IoCallDriver(…, Irp);
> return STATUS_PENDING;
>
> Max
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com