We’ve pretty much got all the trouble worked out of this driver, but when
we turn off debugging and let-er-rip, system gets very busy and apparently
tries to flush everything to reclaim pages. I saw an Access Violation in
our code, so I did a “!stacks 1” debug command. It showed that every
process’ thread has a call first to MmFlushSection, and that is usually
followed by a call to FsRtlCheckLockForReadAccess, followed by calls to
other various routines in the system.
BUT, the running thread that blows up with AV is a call to my
SetFileInformation routine, but with a NULL IrpSp->FileObject. How can
this be? Irp->Flags is usually 0x800 - means IRP_DEFER_IO_COMPLETION?
What does this mean?
TIA - Greg
If the IRP has the IRP_DEFER_IO_COMPLETION flag set, and your dispatch routine did not return STATUS_PENDING, and your completion routine returned STATUS_MORE_PROCESSING_REQUIRED, then the IRP probably had the IO completion APC run twice. Once by you calling IoCompleteRequest from a worker thread, and once by the “IO Manager” calling IopCompleteRequest directly in the context of the original caller. This is a known badness that leads to things like blue screens.
-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, May 29, 2002 2:51 PM
To: File Systems Developers
Subject: [ntfsd] MmFlushSection and access violation
We’ve pretty much got all the trouble worked out of this driver, but when
we turn off debugging and let-er-rip, system gets very busy and apparently
tries to flush everything to reclaim pages. I saw an Access Violation in
our code, so I did a “!stacks 1” debug command. It showed that every
process’ thread has a call first to MmFlushSection, and that is usually
followed by a call to FsRtlCheckLockForReadAccess, followed by calls to
other various routines in the system.
BUT, the running thread that blows up with AV is a call to my
SetFileInformation routine, but with a NULL IrpSp->FileObject. How can
this be? Irp->Flags is usually 0x800 - means IRP_DEFER_IO_COMPLETION?
What does this mean?
TIA - Greg
You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%
Greg,
In addition to the other observation(s)…
You should not be calling FsRtlCheckLockForReadAccess in the paging I/O
write path. This routine is itself pageable (or it should be) and you do
not enforce byte range locks for paging I/O (paging I/O controls USER level
I/O activity, not OS level I/O activity).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class October 7, 2002!
-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, May 29, 2002 2:51 PM
To: File Systems Developers
Subject: [ntfsd] MmFlushSection and access violation
We’ve pretty much got all the trouble worked out of this driver, but when
we turn off debugging and let-er-rip, system gets very busy and apparently
tries to flush everything to reclaim pages. I saw an Access Violation in
our code, so I did a “!stacks 1” debug command. It showed that every
process’ thread has a call first to MmFlushSection, and that is usually
followed by a call to FsRtlCheckLockForReadAccess, followed by calls to
other various routines in the system.
BUT, the running thread that blows up with AV is a call to my
SetFileInformation routine, but with a NULL IrpSp->FileObject. How can
this be? Irp->Flags is usually 0x800 - means IRP_DEFER_IO_COMPLETION?
What does this mean?
TIA - Greg
Tony -
I call FsRtlCheckLockForReadAccess in Read and
FsRtlCheckLockForWriteAccess in write, only if the Irp->Flags
IRP_PAGING_IO flag is NOT set. Is this correct?
The previous observation(s) from Rob Fuller also imply that I have already
processed this irp. I’m not sure if I have processed it already, because
this problem won’t manifest itself if the debugger is running, and the
system is too busy for FileMon!
I’m also not completing any irps with “status_more_processing_required”
anywhere in my code, and I don’t specify any completion routines??? I
thought that was for filter drivers…
I also noticed that the Irp doesn’t look right - the
Irp->CurrentLocation field is larger that the stack count, by two. Is
this possible?
Sorry my mistake. Yes that is for filter drivers. People writing file systems are relatively rare.
-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, May 29, 2002 3:55 PM
To: File Systems Developers
Subject: [ntfsd] RE: MmFlushSection and access violation
Tony -
I call FsRtlCheckLockForReadAccess in Read and
FsRtlCheckLockForWriteAccess in write, only if the Irp->Flags
IRP_PAGING_IO flag is NOT set. Is this correct?
The previous observation(s) from Rob Fuller also imply that I have already
processed this irp. I’m not sure if I have processed it already, because
this problem won’t manifest itself if the debugger is running, and the
system is too busy for FileMon!
I’m also not completing any irps with “status_more_processing_required”
anywhere in my code, and I don’t specify any completion routines??? I
thought that was for filter drivers…
I also noticed that the Irp doesn’t look right - the
Irp->CurrentLocation field is larger that the stack count, by two. Is
this possible?
You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%
Greg,
Correct - don’t check byte locks if IRP_PAGING_IO is set.
Rob’s observation is consistent with what you said (Irp->CurrentLocation
field is +2 from the stack count. That’s where it ends when it is done
processing.)
This doesn’t need to be related to filters. It can (and sounds like it is)
related to your IRP handling logic. Look for someplace where you call
IoMarkIrpPending but return something OTHER THAN STATUS_PENDING. That will
trigger this problem…
There is a timing issue here somewhere - slow things down and the IRP gets
processed before you return to the I/O Manager and the system is OK. Speed
things up and the IRP processing gets delayed until AFTER you return to the
I/O Manager and then the IRP gets completed AFTER you’ve called
IopCompleteRequest - and then bad things happen.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, May 29, 2002 4:55 PM
To: File Systems Developers
Subject: [ntfsd] RE: MmFlushSection and access violation
Tony -
I call FsRtlCheckLockForReadAccess in Read and
FsRtlCheckLockForWriteAccess in write, only if the Irp->Flags
IRP_PAGING_IO flag is NOT set. Is this correct?
The previous observation(s) from Rob Fuller also imply that I have already
processed this irp. I’m not sure if I have processed it already, because
this problem won’t manifest itself if the debugger is running, and the
system is too busy for FileMon!
I’m also not completing any irps with “status_more_processing_required”
anywhere in my code, and I don’t specify any completion routines??? I
thought that was for filter drivers…
I also noticed that the Irp doesn’t look right - the
Irp->CurrentLocation field is larger that the stack count, by two. Is
this possible?
You guys are right on the money again! Thanks a lot for the help - It
took a while, but I found my bug - I was marking some irps pending without
returning STATUS_PENDING.
Thanks to you again!
Greg