CcFlushCache problem.

NTFSD
1

I get the following bugcheck from time to time:

kd> !analyze -v
****************************************************************************
***
* *
* Bugcheck Analysis *
* *
****************************************************************************
***
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00fe0004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804f2c51, address which referenced memory
Debugging Details:

Database SolnDb not connected
READ_ADDRESS: 00fe0004
CURRENT_IRQL: 2
FAULTING_IP:
nt!CcFlushCache+57
804f2c51 8b7004 mov esi,[eax+0x4]
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 804f36fe to 804f2c51
TRAP_FRAME: f995fc18 – (.trap fffffffff995fc18)
ErrCode = 00000000
eax=00fe0000 ebx=00000000 ecx=00000000 edx=00000000 esi=80ed4ed0
edi=00000000
eip=804f2c51 esp=f995fc8c ebp=f995fcf4 iopl=0 nv up ei pl zr ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010256
nt!CcFlushCache+57:
804f2c51 8b7004 mov esi,[eax+0x4]
Resetting default context
STACK_TEXT:
f995fcf4 804f36fe 00fe0000 00000000 00000001 nt!CcFlushCache+0x57
f995fd34 804ee99d 80f5d030 8054eda0 80f2eda8 nt!CcWriteBehind+0xd7
f995fd74 804ed629 80f5d030 00000000 80f2eda8 nt!CcWorkerThread+0x116
f995fdac 8057c73a 80f5d030 00000000 00000000 nt!ExpWorkerThread+0xfe
f995fddc 805124c1 804ed556 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!CcFlushCache+57
804f2c51 8b7004 mov esi,[eax+0x4]
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!CcFlushCache+57
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c
STACK_COMMAND: .trap fffffffff995fc18 ; kb
BUCKET_ID: 0xA_nt!CcFlushCache+57
Followup: MachineOwner

Can anyone give me a point to the possible reasons of such a bugcheck? Does
anyone know protos of CcWorkerThread/CcWriteBehind/CcFlushCache? How can I
find what file object Cc tried to flush?

-htfv

2

Alexey,

What are the conditions required to cause this bug check? i.e. do you have
multiple processes accessing the same file?

It looks like you have a locking problem, as CcFlushCache() takes a
section
object pointer as the first parameter and it maybe bogus… If this is the
case then you have something else (another thread) in the system that has
torn down the associated file meta data (removing references on the file
hence the sections objects i.e CCB’s and then the FCB), and the lazy
writer has come along with the intention of doing its task by flushing
data to disk, to a file that no longer exists (something along those lines
any way).

Have had a lot of “fun” in the past with the lazy writer and synchronizing
it with general file operations. You really have to be careful to maintain
you locking heirarchy, any issues there will bite you with the write
behind thread.

Ian