Diagnose Access Violation in FsRtlAcquireFileForModWrite

OSR_Community_User · January 16, 2002, 3:40pm

I am still having a problem with the lazy writer thread, running on a very
busy win2k server, SP2 system.

I’ve got my own FSD that causes the system to bugcheck with Access
Violation C0000005 in FsRtlAcquireFileForModWrite, and I need some help
figuring this out. If anyone has any suggestions on how to debug this one,
please advise… I’ve included a snippet from the dump below.

Thanks in advance…

Greg Pearce

The dump shows:

Arg1: c0000005, The exception code that was not handled
Arg2: 8049b298, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

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

EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000000
READ_ADDRESS: 00000000 Unknown
DEFAULT_BUCKET_ID: DRIVER_FAULT
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=81f63f10 ebx=80065674 ecx=00000000 edx=00000000 esi=e2672728
edi=8187f928
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 8187f928 82084f78 82084f9c
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

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

OSR_Community_User · January 16, 2002, 4:57pm

The fast i/o dispatch table in the driver object is NULL.
There are 2 possibilities here:
1.) You have forgotten to initialize your fast i/o dispatch
table for your file system’s driver object. If this is the case, you’d
bugcheck pretty consistently & pretty early on in the game
2.) The base file system device object for the file-object is
not correct: i.e. the Vpb is broken. Examine
FileObject->Vpb->DeviceObject.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, January 16, 2002 7:39 AM
To: File Systems Developers
Subject: [ntfsd] Diagnose Access Violation in
FsRtlAcquireFileForModWrite

I am still having a problem with the lazy writer thread, running on a
very
busy win2k server, SP2 system.

I’ve got my own FSD that causes the system to bugcheck with Access
Violation C0000005 in FsRtlAcquireFileForModWrite, and I need some help
figuring this out. If anyone has any suggestions on how to debug this
one,
please advise… I’ve included a snippet from the dump below.

Thanks in advance…

Greg Pearce

The dump shows:

Arg1: c0000005, The exception code that was not handled
Arg2: 8049b298, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

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

EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000000
READ_ADDRESS: 00000000 Unknown
DEFAULT_BUCKET_ID: DRIVER_FAULT
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=81f63f10 ebx=80065674 ecx=00000000 edx=00000000 esi=e2672728
edi=8187f928
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 8187f928 82084f78 82084f9c
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

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

OSR_Community_User · January 17, 2002, 7:24am

Thanks Ravi -

After looking around a lot more, and finally heeding Tony Mason’s previous
post on this subject, I discovered that my ERESOURCE for the particular Fcb
was getting freed while the lazy page writer was (getting ready to) using
it! I think I’ve figured out the problem, but I still have questions…

Does anyone know of a way to make the lazy page writer run when I want
it to, for testing?
If I set the ERESOURCE pointer to NULL after I free it, will the Lazy
writer leave it alone? Or must it always be non-zero?
What would be a good way to know if the ERESOURCE is being used so that
I don’t free it? Is there a function call to determine if the thing is in
use?

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

OSR_Community_User · January 17, 2002, 11:03am

> 3) What would be a good way to know if the ERESOURCE is being used so that

I don’t free it? Is there a function call to determine if the thing is in
use?

Free ERESOURCE only in CLOSE path together with the FCB.
Do this only if there are no more file objects referencing this FCB.

Since Cc holds a reference on the file object, and thus delaying CLOSE, you will be safe.

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

OSR_Community_User · January 18, 2002, 10:33am

Thanks Max, but I’m still confused. I free it when “my” FileReferenceCount
counter is zero, but since the lazy page writer didn’t increment it, I
don’t know if it (or anything else in the system) “has” it. I now attempt
to acquire the resource exclusivly, and if I can, then I free it. If I
cannot, I wait until I can get it, then free it. I’m using
ExAcquireSharedStarveExclusive with wait option set to true.

This is probably not the right thing to do, now that I studied FastFast
example for “close” more closely. They return from close with
STATUS_PENDING if the resource cannot be acquired instead of waiting. (I
saw something in this newsgroup a while back about close must always
complete with status_success!?!?). If I return status_pending, will the
system eventually issue another close to me?

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

OSR_Community_User · January 18, 2002, 12:57pm

I’m replying to the second part of your mail.

Have you looked into FatFsdClose() more deeply?
There is a call to FatCommonClose(), which is
the routine trying to acquire the volume lock.
The FatCommonClose() has one argument Wait, which
can be set to FALSE by FatFsdClose(), but is always
TRUE from FatFspClose(). And additionally, if the
FatCommonClose() returns STATUS_PENDING to the
FatFsdClose() or the FCB is marked as delayed close,
the request is queued and done in some worker thread
later, however, the original IRP_MJ_CLOSE request is
ALWAYS COMPLETED immediately before returning from
the FatFsdClose().

Also note, that in contrast to other “common” routines, the
FatCommonClose() doesn’t receive Irp, but some extracted
parameters, because when called from FatFspClose() the
corresponding Irp has already been completed.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Greg Pearce
Sent: Friday, January 18, 2002 10:32 AM
To: File Systems Developers
Subject: [ntfsd] RE: Diagnose Access Violation in
FsRtlAcquireFileForModWrite

Thanks Max, but I’m still confused. I free it when “my” FileReferenceCount
counter is zero, but since the lazy page writer didn’t increment it, I
don’t know if it (or anything else in the system) “has” it. I now attempt
to acquire the resource exclusivly, and if I can, then I free it. If I
cannot, I wait until I can get it, then free it. I’m using
ExAcquireSharedStarveExclusive with wait option set to true.

This is probably not the right thing to do, now that I studied FastFast
example for “close” more closely. They return from close with
STATUS_PENDING if the resource cannot be acquired instead of waiting. (I
saw something in this newsgroup a while back about close must always
complete with status_success!?!?). If I return status_pending, will the
system eventually issue another close to me?

Thanks - Greg

You are currently subscribed to ntfsd as: xxxxx@compelson.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

OSR_Community_User · January 19, 2002, 3:16pm

> Thanks Max, but I’m still confused. I free it when “my” FileReferenceCount

counter is zero, but since the lazy page writer didn’t increment it, I

If the FCB is known to Cc/Mm - then some file object referencing this FCB is known to Cc/Mm too.
The lazy writer cannot access your FCB if it has no file objects pointing to it.

So, it is OK to free the FCB when all file objects are closed - in the CLOSE handler of the last file object.

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

OSR_Community_User · January 31, 2002, 4:19pm

Finally, after lots of hair-pulling, I figured this out, sort of. A
Looooong time ago I came to the conclusion, with the help of others in this
group, that I had to disable DFS to get my driver to work. The real
(correct) thing to do was figure out why my driver didn’t work with DFS in
the first place, so that’s what I have been doing since my last post to
this newsgroup.

I was not processing the input user buffers right for dfs on
query_directory. Now that I fixed that, DFS no longer bugchecks, and as a
result, neither does the lazy page writer thread.

What I still can’t figure out is this: Is there some connection between
the lazy page writer and DFS? Why would fixing a bug with DFS make the
other problem go away?

Thanks for all the advice and clues, which ultimatly helped me understand a
lot more about FSDs and the system.

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