Help Please! FSD failure in FsRtlAcquireFileForModWrite

NTFSD
1

Hello All -

I have an FSD that blows up (Access Violation C0000005) in a system thread
when trying to do a FsRtlAcquireFileForModWrite. I can’t find doc on this
function and I need to know what IRP is causing the failure. The Call
Stack looks like this:

f2473d74 8043ce2e nt!FsRtlAcquireFileForModWrite+0x18
f2473da8 80454fde nt!MiMappedPageWriter+0xaa
f2473ddc 8046a302 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

It does appear that this is for paging I/O, or OpLocks, neither of which my
FSD supports.

Can anyone PLEASE help me here? I’m at a loss for what to do next, and I’m
running out of time…!

Thanks, ahead of time.

Greg

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

2

Well, the system thread you are reffering is a system thread , the so called
modified page write thread, which asynchronously writes out modified pages
out to disk. the prototype of FsRtlAcquireFileForModWrite is (best to my
knowledge)

BOOLEAN __stdcall _FsRtlAcquireFileForModWrite@12(PFILE_OBJECT
FileObject,PLARGE_INTEGER EndingOffset,PERESOURCE AcquiringResource);

At the time the modified page writter is calls this function, a IRP has
not yet been sent down to the file system stack. The routine which actualy
buids a pagin IO IRP and sends it down to FSD is IoAsynchronousPageWrite.
The file object should be the file object of one of the system pagefiles.
Now , what your routine basically does is

  1. Get the BaseFileSystemDeviceObject (this kind of FASTIO call is always
    sent down to the base file system, circumventing all filter driver
    installed.)
  2. Get it’s driver object , and from the driver object a pointer to the
    driver’s FASTIO dispatch table,
  3. Verify the size of the FASTIO table is big enough to hold a pointer to
    this particular fast io call whithin it , and ensures the retrieved entry
    point is non null.
  4. Call the AcquireModWrite FASTIO point , passing to it
    (FileObject,EndingOffset,AcquiringResource,BaseFileSystemDeviceObject)

Tracing the 2k kernel live , we see that at offset 0x18 in this call we
have:

0xD call _IoGetBaseFileSystemDeviceObject
;in EAX , base file system device
0x12 mov ecx, [DEVICE_OBJECT.DriverObject] ;
fetch it’s DRIVER_OBJECT
0x15 mov ecx, [DRIVER_OBJECT.FastIoDispatch]
;fetch a pointer to the FASTIO table
0x18 cmp dword ptr [FASTIO_DISPATCH.Size], 3Ch //
FASTIO table big enough ?

Depending what exact kernel you run , the fault can be elsewhere , but I
really think your FSD does not properly support this fastio , moreover ,
your FASTIO table is not initialized corectly(if at all) the only real
faults of this type can be in somewhere this short range only.

Regards , Dan

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Wednesday, December 26, 2001 9:24 AM
Subject: [ntfsd] Help Please! FSD failure in FsRtlAcquireFileForModWrite

> Hello All -
>
> I have an FSD that blows up (Access Violation C0000005) in a system thread
> when trying to do a FsRtlAcquireFileForModWrite. I can’t find doc on this
> function and I need to know what IRP is causing the failure. The Call
> Stack looks like this:
>
> f2473d74 8043ce2e nt!FsRtlAcquireFileForModWrite+0x18
> f2473da8 80454fde nt!MiMappedPageWriter+0xaa
> f2473ddc 8046a302 nt!PspSystemThreadStartup+0x54
> 00000000 00000000 nt!KiThreadStartup+0x16
>
> It does appear that this is for paging I/O, or OpLocks, neither of which
my
> FSD supports.
>
> Can anyone PLEASE help me here? I’m at a loss for what to do next, and
I’m
> running out of time…!
>
> Thanks, ahead of time.
>
> Greg
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> 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

3

Thanks Dan - I appreciate the quick response!

I will admit that I’m still pretty new to all this stuff, and I’m amazed at
how quickly you responded and figured this out. I have a lot to learn!

My driver is a FSD, not a FSFD, and it’s running on win2k. I don’t support
fast i/o or paging at all, so I’m trying to figure out why this request
came to my FSD in the first place.

When the system inits my FSD, doesn’t it ask if fast i/o is possible, then
it remembers that (in the device object?) and should not attempt fast i/o
to my device? I also tell the I/O mgr that I don’t support paging… so
I’m confused as to why anything/anyone is bothering my FSD with these
IRPs.

Any more of your insight into this would be VERY welcome, and appreciated.

Thanks - Greg

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

4

Greg,

FsRtlAcquireForModWrite is not called during an IRP. It actualy preceeds
always
an IRP for asynchronous paging writes , and the source is the the memory
manager.
I wanna ask , is there any pattern you seen before this fault ? If so pls
tell us.

And btw , yesterday I bringed myself my share of stupidity to this list , I
confunded in a hurry the modified
page writer thred , which writes to pagefiles , with the mapped page writter
thread , which deals
with memory mapped files.

Regards , Dan

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Thursday, December 27, 2001 12:00 PM
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM-
odWrite

> Tony,
>
> I just discovered that I do actually set the
> FileObject->SectionObjectPointers field… so I do support memory mapped
> files (DOH!). The file in question wasn’t previously opened by Notepad,
> but the program that does open it probably is (or MUST be) using memory
> mapped files.
>
> What I meant when I stated that “I also tell the I/O mgr that I dont
> support paging” is really that I check a flag in the stack location
> (SL_OPEN_PAGING_FILE) when I get an open request and fail the IRP with
> “STATUS_ACCESS_DENIED” if it is paging I/O.
>
> I should also add that I have determined that my FSD does not have a fast
> i/o dispatch table at all, so I’m sure it doesn’t support fast i/o.
>
> So I guess that answers that - about the memory mapped files - but I still
> can’t understand why I’m getting the access violation in
> FsRtlAcquireFileForModWrite. I can open files with notepad and it works
> fine. I’d like to figure out which IRP is causing this to happen so I can
> set a breakpoint on it’s processing routine and see what’s going on.
>
> Again, I really appreciate any help you (and anyone else) can provide…
>
> Thanks - Greg
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> 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

5

Dan,

I don’t see a pattern, except that it is reproducable by running a
particular third-party application that tries to memory-map a file that it
gets from my file system. It is a very I/O intensive application, and
there are several instances of it running at the same time, in the same
user context. I have been hunting around some more (in the dump) to try to
figure out what’s up, and I think this problem is occuring because my FSD
isn’t using the right user context to process requests, but I’m not sure
yet.

I finally got a test environment that will allow me to do active debugging
(instead of post-mortem), so maybe I’ll make some progress today, and have
an update for this list.

Thanks again for your (and everyone else’s) help, and I wish you all the
best in the coming new year.

Regards,

Greg

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