Re: Help Please! FSD failure in FsRtlAcquireFileForM- - odWrite

NTFSD
1

Greg,

Well, lots of issues to address in this one:

Well, setting the SectionObjectPointers field tells the memory manager you
will support paging I/O. That explains why you are getting the access
violation in FsRtlAcquireFileForModWrite (it is attempting to acquire a lock
to ensure the file does not shrink while writing out changes. You just
aren’t supporting the model!) If you DO implement the fast I/O routine,
then you can implement your own locking there. Otherwise, it is going to
acquire either the FCB->Resource (That is, the FileObject->FsContext field
cast to the common header format (FSRTL_FCB_COMMON_HEADER or somesuch - I
don’t have the IFS kit installed on the computer I’m using at the moment. In
the XP kit there is a superset version - the ADVANCED_COMMON_HEADER variant)
or the PagingIoResource, depending upon the setting of the FCB->Flags field
as well. I suspect you aren’t setting the FCB->Resource field to point to
an ERESOURCE. Without the fast I/O entry point the FsRtl package acquires
the ERESOURCE - but if you don’t initialize it, the OS will fault.

You can choose to do one of several things:

  • Don’t support paging I/O. Do this by NOT setting the SectionObjectPointers
    structure.
  • Implement a fast I/O entry point, use your own locking model
  • Allocate and initialize an ERESOURCE for your FCB

The SL_OPEN_PAGING_FILE has to do with a special file used by the OS to
store temporary data (that is, the file called “pagefile.sys”) and does NOT
apply to an arbitrary file that will be accessed via the Paging I/O
mechanism. The two concepts, while similarly named, are very different from
the perspective of a file system. Very special rules apply to paging files
(NO page faults are allowed. You have to assume DISPATCH_LEVEL IRQL rules,
but you don’t actually operate at DISPATCH_LEVEL - you are allowed to block
and wait for external operations like disk I/O.)

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Come join us at the next OSR file systems class in March, 2002!

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, December 26, 2001 8:00 PM
To: File Systems Developers
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@osr.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

2

Tony,

Thanks for the information - I checked most of this out and have found that
I do initialize an ERESOURCE and save it’s address in the
FSRTL_COMMON_FCB_HEADER, then I set the section object pointer. My routine
looks like the following example: (The GCB is our “Generic” control block,
and it’s header is of type FSRTL_COMMON_FCB_HEADER)

PPCB Pcb;
PERESOURCE Ptr;
ULONG Size = sizeof (GCB) + NameLength;

Gcb = ExAllocatePool (PagedPool, Size);
if (Gcb eq NULL) then try_return (Iosb);

RtlZeroMemory (Gcb, Size);
Gcb->Header.NodeByteSize = (USHORT) Size;

Gcb->Name.MaximumLength = NameLength;
Gcb->FullName.MaximumLength = NameLength;
FsdSetFileContext (Request, Gcb);

Size = sizeof (PCB) + sizeof (ERESOURCE);
Pcb = ExAllocatePool (NonPagedPool, Size);
if (Pcb eq NULL) then try_return (Iosb);

Gcb->Pcb = Pcb;
RtlZeroMemory (Pcb, Size);

Ptr = (PERESOURCE)(CL (Pcb) + sizeof (PCB));
Gcb->Header.Resource = Ptr;
ExInitializeResource (Gcb->Header.Resource);
FsdSetSectionObject (Request, Gcb);

Iosb.Status = STATUS_SUCCESS;

FsdSetSectionObject just does the following:

PSECTION_OBJECT_POINTERS SectionObject;
PFILE_OBJECT FileObject = Request->FileObject;

if (NodeType (Context) eq VolumeControlBlock) then
SectionObject = NULL;
else
SectionObject = &((PGCB) Context)->Pcb->Sop;

FileObject->SectionObjectPointer = SectionObject;

So it looks like the support is there for paging requests for memory mapped
files. Just to see what happens, I made it so that the section object
pointer was always NULL, and Notepad stopped working. (No surprise there,
I suppose!).

Could it be that this problem is caused by overlapped I/O? I’m just
guessing here because I think this FSD was originally written before
overlapped I/O (the first version of FSD started in NT 3.51). I think that
overlapped I/O is occuring on a memory mapped file (is this possible?), and
that I am not properly managing the user context pointers. If I have two
or more user contexts going on at the same time, the FSD might be getting
the wrong one from the list I’m maintaining, and I could be confusing the
system by completing the wrong IRP. I noticed in the memory.dmp that I
have some locks held, and something looks fishy in the command output.
Here it is:

0: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ 0x82099934 Shared 1 owning threads
Contention Count = 76
Threads: 819aec60-01
KD: Scanning for held locks…

Resource @ 0x81ebe0c8 Shared 1 owning threads
Threads: 819ad080-02
KD: Scanning for held
locks…

Resource @ 0x81a3e108 Exclusively owned
Contention Count = 7
Threads: 819aec60-01
KD: Scanning for held locks…

Resource @ 0x82091d88 Exclusively owned
Threads: 819aec60-01
KD: Scanning for held locks…

Resource @ 0x81917394 Exclusively owned
Threads: 819b8da0-01
KD: Scanning for held locks.

Resource @ 0x81ed0240 Shared 1 owning threads
Threads: 819ad083-01 *** Invalid thread
3840 total locks, 6 locks currently held

This last one looks bad, but I don’t know the debugger well enough yet to
get more information about it, but I’m trying!

I am very grateful to have you guys (everyone on this list) out there
helping me out - Thanks AGAIN and I give you my best regards for this and
the coming new year.

Happy Holidays!

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