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

I’m still having a problem with FsRtlAcquireFileForModWrite (I know, I
said I thought I fixed it, but…)

I now know that I am handling user buffers properly, (not that this had
any bearing on this problem), but I wasn’t before and it was causing
serious problems.

I also now have a PagingIoResource defined and initialized in the
common_fcb_header (as well as a main resource initialized and specified
(“Resource”)), and I do set a section object pointer in the file object,
which is a pointer of type “PSECTION_OBJECT_POINTERS”, and I do NOT have a
fast i/o dispatch table at all.

The Section Object Pointer logic was added prior to me inheriting this
FSD, but I think this was to support memory mapped I/O (so notepad would
work when reading a file on my device).

I’m still confused about what the FsRtlAcquireFileForModWrite
function is actually doing - When a file is read into memory for memory
mapped I/O, and the system needs to reclaim virtual memory pages because
of a low memory condition, is this when this function runs?

Do I have to include any callback functions for cache manager in this
case? I noticed this in fastfat example, but I don’t support cached file
I/O, unless this is really what is going on here with memory mapped I/O.
I don’t understand the difference, I guess.

I have included the basic stuff from the dump, below. If anyone has a
chance to take a second look at this, I’d be forever grateful.

Thanks again, and regards -

Greg Pearce

BUGCHECK_STR: 1E

EXCEPTION_RECORD: f2473ca0 – (.exr fffffffff2473ca0)
ExceptionAddress: 8049b298 (nt!FsRtlAcquireFileForModWrite+0x00000018)
ExceptionCode: c0000005
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000

CONTEXT: f24738f8 – (.cxr fffffffff24738f8)
eax=81f662d0 ebx=80065674 ecx=00000000 edx=00000000 esi=e2158be8
edi=818ab548
eip=8049b298 esp=f2473d68 ebp=f2473d74 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
nt!FsRtlAcquireFileForModWrite+18:
8049b298 83393c cmp dword ptr [ecx],0x3c
Resetting default context

LAST_CONTROL_TRANSFER: from 8043ce2e to 8049b298

STACK_TEXT:
f2473d74 8043ce2e 818ab548 82085938 8208595c
nt!FsRtlAcquireFileForModWrite+0x18
f2473da8 80454fde 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
f2473ddc 8046a302 8043cd84 00000000 00000000
nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!FsRtlAcquireFileForModWrite+18
8049b298 83393c cmp dword ptr [ecx],0x3c

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!FsRtlAcquireFileForModWrite+18

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp

STACK_COMMAND: .cxr fffffffff24738f8 ; kb

BUCKET_ID: 0x1E_nt!FsRtlAcquireFileForModWrite+18

Followup: MachineOwner

Figure out what offset 0x3c corresponds to in the FSRTL_COMMON_FCB_HEADER and FAST_IO_DISPATCH structures. Look like anything suspicious?

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Tuesday, February 26, 2002 1:37 PM
To: File Systems Developers
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

I’m still having a problem with FsRtlAcquireFileForModWrite (I know, I
said I thought I fixed it, but…)

I now know that I am handling user buffers properly, (not that this had
any bearing on this problem), but I wasn’t before and it was causing
serious problems.

I also now have a PagingIoResource defined and initialized in the
common_fcb_header (as well as a main resource initialized and specified
(“Resource”)), and I do set a section object pointer in the file object,
which is a pointer of type “PSECTION_OBJECT_POINTERS”, and I do NOT have a
fast i/o dispatch table at all.

The Section Object Pointer logic was added prior to me inheriting this
FSD, but I think this was to support memory mapped I/O (so notepad would
work when reading a file on my device).

I’m still confused about what the FsRtlAcquireFileForModWrite
function is actually doing - When a file is read into memory for memory
mapped I/O, and the system needs to reclaim virtual memory pages because
of a low memory condition, is this when this function runs?

Do I have to include any callback functions for cache manager in this
case? I noticed this in fastfat example, but I don’t support cached file
I/O, unless this is really what is going on here with memory mapped I/O.
I don’t understand the difference, I guess.

I have included the basic stuff from the dump, below. If anyone has a
chance to take a second look at this, I’d be forever grateful.

Thanks again, and regards -

Greg Pearce

BUGCHECK_STR: 1E

EXCEPTION_RECORD: f2473ca0 – (.exr fffffffff2473ca0)
ExceptionAddress: 8049b298 (nt!FsRtlAcquireFileForModWrite+0x00000018)
ExceptionCode: c0000005
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000

CONTEXT: f24738f8 – (.cxr fffffffff24738f8)
eax=81f662d0 ebx=80065674 ecx=00000000 edx=00000000 esi=e2158be8
edi=818ab548
eip=8049b298 esp=f2473d68 ebp=f2473d74 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
nt!FsRtlAcquireFileForModWrite+18:
8049b298 83393c cmp dword ptr [ecx],0x3c
Resetting default context

LAST_CONTROL_TRANSFER: from 8043ce2e to 8049b298

STACK_TEXT:
f2473d74 8043ce2e 818ab548 82085938 8208595c
nt!FsRtlAcquireFileForModWrite+0x18
f2473da8 80454fde 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
f2473ddc 8046a302 8043cd84 00000000 00000000
nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!FsRtlAcquireFileForModWrite+18
8049b298 83393c cmp dword ptr [ecx],0x3c

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!FsRtlAcquireFileForModWrite+18

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp

STACK_COMMAND: .cxr fffffffff24738f8 ; kb

BUCKET_ID: 0x1E_nt!FsRtlAcquireFileForModWrite+18

Followup: MachineOwner


You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

I don’t support fast i/o, so it might make sense that ecx is null, because
I don’t have a fast i/o dispatch table defined. 3C from the beginning of
the FSRTL_COMMON_FCB_HEADER points to a file name in my extension.

What does this mean? I didn’t want to support fast i/o at all; and why
would this routine be looking into my extension for anything? I’m still
lost.

Thanks - Greg

I just looked at NTDDK.H and 0x3C corresponds to AcquireForModWrite in FASTIO_DISPATCH.

What version of NT is this?

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Tuesday, February 26, 2002 2:50 PM
To: File Systems Developers
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

I don’t support fast i/o, so it might make sense that ecx is null, because
I don’t have a fast i/o dispatch table defined. 3C from the beginning of
the FSRTL_COMMON_FCB_HEADER points to a file name in my extension.

What does this mean? I didn’t want to support fast i/o at all; and why
would this routine be looking into my extension for anything? I’m still
lost.

Thanks - Greg


You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

Greg, That routine looks into your DriverObject , not into your context .

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Tuesday, February 26, 2002 9:50 PM
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

> I don’t support fast i/o, so it might make sense that ecx is null, because
> I don’t have a fast i/o dispatch table defined. 3C from the beginning of
> the FSRTL_COMMON_FCB_HEADER points to a file name in my extension.
>
> What does this mean? I didn’t want to support fast i/o at all; and why
> would this routine be looking into my extension for anything? I’m still
> lost.
>
> Thanks - Greg
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

It’s Win2k Server with SP2…

Oh man… now I’m even more confused! Why is this so darned hard for me
to figure out…

I suspect this version of NT doesn’t support a file system integrated with the VM system that has a NULL FastIoDispatch pointer in its driver object. I do not find this surprising. In fact, I would not be surprised if no version of NT supports this.

There are some hacks you might try, but they may cause other problems. You could set your FastIoDispatch pointer to a FAST_IO_DISPATCH structure initialized to zeros. This will set its SizeOfFastIoDispatch field to zero.

If this doesn’t work, you’re going to have to implement fast IO routines. This doesn’t mean you have to implement fast IO, simply that there are fast IO entry points you will have to define that return FALSE, meaning the caller should build an IRP because you don’t support fast IO. Regardless, you’re probably going to have to learn more about fast IO than perhaps you want.

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Tuesday, February 26, 2002 3:14 PM
To: File Systems Developers
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

It’s Win2k Server with SP2…


You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

Ok , lemme cast a bit of light if I can, altough I vaguely remember , if at
all , all the details of the initial question.

FsRtlAcquireForModWrite works kinda this way:

  1. Puts into a local variable , lets name is CommonHeader the
    FileObject->FsContext.
  2. it gets the base file system device object from the file object
  3. gets the driver object from
  4. lookups the fast io table ptr
  5. checks if the size of the fast io table is large enough to have a handler
    for AcquireForModWrite fastio

/// this step crashes for you , since the ptr to fast io table is NULL and
you read from offset 3C the size of the table
// basicaly you end reading from 0+3c , a memory region which aint valid ->
BSOD

5.checks if the ptr to fastio handler for AcquireForModWrite is non NULL
6. if the ptr is non - null , it calls the FSD AcquireForModWrite

if any of steps 4-5 fails , the routine trys to determine what resource to
acquire mainly this way

assumes that FileObject->FsContext is a PFSRTL_COMMON_FCB_HEADER;

if (!CommonHeader ->Resource)
{
*ResourceAcquired = NULL
return TRUE //// dont acquire any resource
}

then , it checks CommonHeader->Flags and acts acordingly

if (FlagOn(CommonHeader->Flags, FSRTL_FLAG_ACQUIRE_MAIN_RSRC_EX) || some
size extensions checks)
{
Acquire the main resource exclusive

}

if (FlagOn(CommonHeader->Flags, FSRTL_FLAG_ACQUIRE_MAIN_RSRC_SH) &&
!CommonHeader>PagingIoResource )
{
AcquireMainResource shared
}

else
{
Acquire PagingIoResource
}

So my guess is that if you have a proper FSRTL_COMMON_FCB_HEADER as your
first part of context data , you can
alloc a dummy fast io table , zero it completly , and poke a pointer to it
in DriverObject->FastIo to get out of trouble.

Also , I dont know , but it seems to me that failing to check in this
routine if the fast io table ptr is valid in the driver object
sounds like a bug and MS should fix it. Also remember that since I very fast
looked with softice to the code of fsRtl…
the functionality steps I outlined before can be wrong (altough I seriously
doubt it) and you should take this info “as is”

Best regards , Dan

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Tuesday, February 26, 2002 10:19 PM
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

> Oh man… now I’m even more confused! Why is this so darned hard for me
> to figure out…
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

I checked a XP system. In XP , this routine was replaces with
FsRtlAcquireForModWriteEx , which corectly checks
if the fast io ptr is null or not. So I do beleive the behaviour on 2k is
indeed a OS bug.

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Tuesday, February 26, 2002 10:19 PM
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

> Oh man… now I’m even more confused! Why is this so darned hard for me
> to figure out…
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

Not to mention that 2k implementation of FsRtlAcquireFileForCcFlush
corectly checks for the NULL pointer too.

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Tuesday, February 26, 2002 10:19 PM
Subject: [ntfsd] Re: Help Please! FSD failure in FsRtlAcquireFileForM- -
odWrite

> Oh man… now I’m even more confused! Why is this so darned hard for me
> to figure out…
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

This is good stuff, Don - thanks! I’ll implement a dummy table and let
everyone know what happened… - I really appreciate the help!

Regards,

Greg

Thanks Rob - great answer - I will try this and let you know. I really
appreciate the help…

Regards

Greg

I reported this to MS as a bug and they acknowledged it, and it will be
escalated up the CPR path, and fixed in a subsequent service pack.!!!
Thanks a lot guys for helping me figure this out!

Regards,
Greg