Undesired Cache Manager Interactions?

I am supporting a legacy filter driver that, among others things, rolls
it's own IRPs to perform such tasks as to query information for a file.
One of the things it does perform is that during create processing, it
will roll an IRP, copy most of the state from the old IRP to the new
IRP, sets up the I/O stack and sends it down for processing. Upon
completion and if the status is OK, it will then read the header of the
file (again rolling it's own IRP). Eventually, status is set in the
original IRP and that is completed.

Under heavy load, we are getting some BSODs that all appear like that
indicated below. Some how this filter is causing problems with the
cache manager...any ideas/hints on how to debug this type of problem?

Thanks for any help you may provide.


kd> !analyze -v
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: ecfe93b5, The address that the exception occurred at
Arg3: f7c98c24, Exception Record Address
Arg4: f7c98920, Context Record Address

Debugging Details:

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
Fastfat!FatAcquireFcbForLazyWrite+c
ecfe93b5 3bb0b0010000 cmp esi,[eax+0x1b0]

EXCEPTION_PARAMETER1: f7c98c24

CONTEXT: f7c98920 -- (.cxr fffffffff7c98920)
eax=00000000 ebx=00000000 ecx=85c0b928 edx=f7c98d40 esi=e2aa3008
edi=f7c98d40
eip=ecfe93b5 esp=f7c98cec ebp=f7c98cf0 iopl=0 nv up ei pl zr na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Fastfat!FatAcquireFcbForLazyWrite+0xc:
ecfe93b5 3bb0b0010000 cmp esi,[eax+0x1b0]
ds:0023:000001b0=????????
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from 804ee1c4 to ecfe93b5

STACK_TEXT:
f7c98cf0 804ee1c4 e2aa3008 00000001 80556d10
Fastfat!FatAcquireFcbForLazyWrite+0xc
f7c98d2c 804e54ad 867b5290 80561b40 867b6640 nt!CcWriteBehind+0x27
f7c98d74 804e47fe 867b5290 00000000 867b6640 nt!CcWorkerThread+0x126
f7c98dac 8057dfed 867b5290 00000000 00000000 nt!ExpWorkerThread+0x100
f7c98ddc 804fa477 804e4729 00000000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Fastfat!FatAcquireFcbForLazyWrite+c
ecfe93b5 3bb0b0010000 cmp esi,[eax+0x1b0]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Fastfat!FatAcquireFcbForLazyWrite+c

MODULE_NAME: Fastfat

IMAGE_NAME: Fastfat.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eb7

STACK_COMMAND: .cxr fffffffff7c98920 ; kb

BUCKET_ID: 0x7E_Fastfat!FatAcquireFcbForLazyWrite+c

Followup: MachineOwner

Although I don’t see where is the problem,
I may advice you to look at the source of
FatAcquireFcbForLazyWite into the fastfat
example in the IFS kit. Maybe you’ll be wiser.

L.