CcFlushCache Access Violation - Second Post

I’m getting occasional BugChecks in CCFlushCache due to an access violation,
seems the section pointer is invalid. (This started to occur after I began
posting some reads (IRP) using the FILE OBJECT during cleanup).

Any idea how reading from a FILE OBJECT could cause corruption?



> I’m getting occasional BugChecks in CCFlushCache due

to an access violation, seems the section pointer is invalid.

Create the crash dump, open it using WinDBG and analyze it.
I’m afraid no one is able to help you from the description
you provided.



I have analysed it with windbg but I’m not sure what is going on within the
CcFlushCache call since I have no source.
The parameters to CcFlushCache are zero, which is obviously not good.
The question is how did they get that way? As I said before I suspect
reading from FileObjects during cleanup operations might be causing this.


Here is some info from the dump:

*********** stack trace *************
ChildEBP RetAddr Args to Child
f78e6d00 804fcfda 00000000 00000000 00000001 nt!CcFlushCache+0x5d (FPO:
f78e6d40 804f22ae 85eeb3a0 80582d80 85edeac0 nt!CcWriteBehind+0x116 (FPO:
f78e6d80 804eebdb 85edeac0 00000000 85eeb3a0 nt!CcWorkerThread+0x12c (FPO:
f78e6dac 8059b35e 85edeac0 00000000 00000000 nt!ExpWorkerThread+0xe9 (FPO:
f78e6ddc 805008e6 804eeb10 00000000 00000000 nt!PspSystemThreadStartup+0x2e
(FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

************ dump of first parameter to CcWriteBehind
0: kd> !object 85eeb3a0
Object: 85eeb3a0 Type: (85eede70) Thread
ObjectHeader: 85eeb388
HandleCount: 0 PointerCount: 1
0: kd> dd 85eeb3a0
85eeb3a0 00720006 00000000 85eeb3a8 85eeb3a8
85eeb3b0 85eeb3b0 85eeb3b0 f78e7000 f78e4000
85eeb3c0 f78e6ba8 00000000 000475e0 00010a02
85eeb3d0 00000000 85eeb3d4 85eeb3d4 85eeb3dc
85eeb3e0 85eeb3dc 85eed9b0 00000000 00000000
85eeb3f0 00000000 85eeb440 0d1d0000 00000001
85eeb400 00000000 ffdffab8 80582d80 000a97e8
85eeb410 00000000 00000000 000a0008 00000000
85eeb420 85eeb420 85eeb420 43c64650 00000019
85eeb430 858799e8 8057aae0 00000000 00000000
85eeb440 853c1d08 8057feb4 85eeb3a0 8057feac
85eeb450 85eeb440 00010000 00000000 00000000
85eeb460 85eeb3a0 00000000 00000000 00000000
85eeb470 00000000 00000000 85eeb3a0 00000000
85eeb480 00000000 00000000 85eeb420 85eeb420
85eeb490 85eeb3a0 85eeb418 85eeb440 00010102

************ dump of second parameter to CcWriteBehind
0: kd> !object 80582d80
Object: 80582d80 Type: (00000007)
ObjectHeader: 80582d68
HandleCount: 2247007192 PointerCount: 2247007192
Directory Object: 000185ee Name: (*** Name not accessible ***)
0: kd> dd 80582d80
80582d80 000a0004 00000000 83d400c0 85eebe40
80582d90 80582d90 80582d90 00000001 00000004
80582da0 85eecb70 83d40120 00000006 00024f7a
80582db0 00024f7a 00000000 00000082 000a0004
80582dc0 00000000 85eea0c0 85eeabc0 80582dcc
80582dd0 80582dcc 00000000 00000004 85eea120
80582de0 85ee9120 00000000 00004204 00004204
80582df0 00000000 0000003c 000a0004 00000000
80582e00 85ee9e40 85ee9e40 80582e08 80582e08
80582e10 00000000 00000004 85ee9ea0 85ee9ea0
80582e20 00000000 000110b4 000110b3 00000000
80582e30 00000008 00000000 00000000 00000000
80582e40 85f11960 805778d8 00000000 00000000
80582e50 00000000 00000000 00000000 00000000
80582e60 00000000 00000000 00000000 00000000
80582e70 00000000 00000000 00000000 00000000

************* aseembly code
0: kd> u nt!CcWriteBehind
804fcf20 55 push ebp
804fcf21 8bec mov ebp,esp
804fcf23 83ec1c sub esp,0x1c
804fcf26 53 push ebx
804fcf27 56 push esi
804fcf28 57 push edi
804fcf29 8bf1 mov esi,ecx
804fcf2b 8b8690000000 mov eax,[esi+0x90]
0: kd> u
804fcf31 6a01 push 0x1
804fcf33 ffb694000000 push dword ptr [esi+0x94]
804fcf39 8bfa mov edi,edx
804fcf3b 897df8 mov [ebp-0x8],edi
804fcf3e 33db xor ebx,ebx
804fcf40 ff10 call dword ptr [eax]
804fcf42 84c0 test al,al
804fcf44 0f84de660200 je nt!CcWriteBehind+0x26 (80523628)
0: kd> u
804fcf4a 8d8eb8000000 lea ecx,[esi+0xb8]
804fcf50 8d55e4 lea edx,[ebp-0x1c]
804fcf53 ff15e0f04d80 call dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock
804fcf59 648b0d20000000 mov ecx,fs:[00000020]
804fcf60 81c140040000 add ecx,0x440
804fcf66 e8c589feff call nt!KeAcquireQueuedSpinLockAtDpcLevel
804fcf6b 837e6001 cmp dword ptr [esi+0x60],0x1
804fcf6f 0f870f030000 jnbe nt!CcWriteBehind+0x73 (804fd284)
0: kd> u
804fcf75 8d4e58 lea ecx,[esi+0x58]
804fcf78 e8c387feff call nt!KefAcquireSpinLockAtDpcLevel (804e5740)
804fcf7d 8b5e48 mov ebx,[esi+0x48]
804fcf80 85db test ebx,ebx
804fcf82 0f8562cbffff jne nt!CcWriteBehind+0x88 (804f9aea)
804fcf88 8b7df8 mov edi,[ebp-0x8]
804fcf8b 8d4e58 lea ecx,[esi+0x58]
804fcf8e e81d88feff call nt!KefReleaseSpinLockFromDpcLevel
0: kd> u
804fcf93 8b4674 mov eax,[esi+0x74]
804fcf96 ff4604 inc dword ptr [esi+0x4]
804fcf99 85c0 test eax,eax
804fcf9b 0f8510920000 jne nt!CcWriteBehind+0xba (805061b1)
804fcfa1 648b0d20000000 mov ecx,fs:[00000020]
804fcfa8 81c140040000 add ecx,0x440
804fcfae e8dd89feff call nt!KeReleaseQueuedSpinLockFromDpcLevel
804fcfb3 8d4de4 lea ecx,[ebp-0x1c]
0: kd> u
804fcfb6 ff15e4f04d80 call dword ptr [nt!_imp_KeReleaseInStackQueuedSpinLock
804fcfbc 85db test ebx,ebx
804fcfbe 0f8541cbffff jne nt!CcWriteBehind+0xf5 (804f9b05)
804fcfc4 8b7df8 mov edi,[ebp-0x8]
804fcfc7 8b4644 mov eax,[esi+0x44]
804fcfca 57 push edi
804fcfcb 6a01 push 0x1
804fcfcd 68787a5780 push 0x80577a78
0: kd> u
804fcfd2 ff7014 push dword ptr [eax+0x14]
804fcfd5 e856e9ffff call nt!CcFlushCache (804fb930)
804fcfda ffb694000000 push dword ptr [esi+0x94]
804fcfe0 8b8690000000 mov eax,[esi+0x90]
804fcfe6 ff5004 call dword ptr [eax+0x4]
804fcfe9 8b07 mov eax,[edi]
804fcfeb 33db xor ebx,ebx
804fcfed 3bc3 cmp eax,ebx

************* assembly code
0: kd> u nt!CcFlushCache
804fb930 55 push ebp
804fb931 8bec mov ebp,esp
804fb933 83ec60 sub esp,0x60
804fb936 8b4514 mov eax,[ebp+0x14]
804fb939 53 push ebx
804fb93a 56 push esi
804fb93b 57 push edi
804fb93c 33ff xor edi,edi
0: kd> u
804fb93e 3bc7 cmp eax,edi
804fb940 897de8 mov [ebp-0x18],edi
804fb943 897ddc mov [ebp-0x24],edi
804fb946 897dec mov [ebp-0x14],edi
804fb949 897df8 mov [ebp-0x8],edi
804fb94c 897df0 mov [ebp-0x10],edi
804fb94f 897dd8 mov [ebp-0x28],edi
804fb952 897de4 mov [ebp-0x1c],edi
0: kd> u
804fb955 0f841bc8ffff je nt!CcFlushCache+0x27 (804f8176)
804fb95b 8b5d0c mov ebx,[ebp+0xc]
804fb95e 81fb787a5780 cmp ebx,0x80577a78
804fb964 8938 mov [eax],edi
804fb966 897804 mov [eax+0x4],edi
804fb969 7512 jnz nt!CcFlushCache+0x4f (804fb97d)
804fb96b c70016000080 mov dword ptr [eax],0x80000016
804fb971 c745f801000000 mov dword ptr [ebp-0x8],0x1
0: kd> u
804fb978 897d0c mov [ebp+0xc],edi
804fb97b 8bdf mov ebx,edi
804fb97d 6a05 push 0x5
804fb97f 59 pop ecx
804fb980 ff15f8f04d80 call dword ptr [nt!_imp_KeAcquireQueuedSpinLock
804fb986 8ad0 mov dl,al
804fb988 8b4508 mov eax,[ebp+0x8]
804fb98b 8b7004 mov esi,[eax+0x4]

-----Original Message-----
From: Ladislav Zezula []
Sent: Wednesday, November 24, 2004 1:30 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] CcFlushCache Access Violation - Second Post

I’m getting occasional BugChecks in CCFlushCache due
to an access violation, seems the section pointer is invalid.

Create the crash dump, open it using WinDBG and analyze it.
I’m afraid no one is able to help you from the description
you provided.


Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as:
To unsubscribe send a blank email to