Curious case of CC ASSERT failure(File System)

Hi NTFSD,

I am develpoing a file system driver. During some regression testing,I get this system ASSERT failure-

Assertion failed: ControlArea->u.Flags.BeingPurged == 0
*** Source File: d:\xpsprtm\base\ntos\mm\mapcache.c, line 166

It occurs when I run an automation tool which performs almost all normal file operations( Create, Read, Write, query/set file/volume information etc) in an infinite fashion.

If I ignore that ASSERT, it works fine, even with driver verifier enabled.

But it looks something suspecious to me.

Any insight on this ASSERT and its possible cause of failure?
Details are below.

ASSERT:

*** Assertion failed: ControlArea->u.Flags.BeingPurged == 0
*** Source File: d:\xpsprtm\base\ntos\mm\mapcache.c, line 166

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread (boipt)? b

STACK TRACE:

ChildEBP RetAddr Args to Child

00 eef6a7f0 80a9208c 80a91cdc 80a91cb8 000000a6 nt!RtlAssert+0x18
01 eef6a82c 80a18376 e128b430 869f81b0 eef6a858 nt!MmMapViewInSystemCache+0x146
02 eef6a89c 80a18823 86689510 008dc000 00000000 nt!CcGetVacbMiss+0x304
03 eef6a8c8 80a12301 866895e0 008dc000 00000000 nt!CcGetVirtualAddress+0xc9
04 eef6a958 80a0f00e 86689510 e27d4000 eef6a99c nt!CcMapAndCopy+0xe9
05 eef6a9e8 ee5b0981 865bc578 eef6aa2c 00001000 nt!CcCopyWrite+0x2a6
06 eef6aa54 ee5b5ceb 86575200 86617880 000008dc myFSD!UpdateNodeToCache+0x141
07 eef6aa68 ee5b5cbe ee18dee5 86617788 8bac4e70 myFSD!UpdateINodeFromFcb+0x45b
08 eef6aad4 ee5cbfb7 86575200 861206e8 8a94ce90 myFSD!UpdateINodeFromFcb+0x42e
09 eef6abd8 ee5cb5a2 86575200 8bac4e70 ee18d811 myFSD!CommonCleanup+0x997
0a eef6ac20 80a21a41 86617788 8bac4e70 86617788 myFSD!FsdCleanup+0xc2
0b eef6ac38 80cd4128 861206e8 8bac4e70 8bac4e80 nt!IopfCallDriver+0x51
0c eef6ac5c 80b3718b 80102524 86a2de70 86a2df04 nt!IovCallDriver+0xa0
0d eef6ac88 80badf1c 869a24c0 861206e8 00100081 nt!IopCloseFile+0x29d
0e eef6acc0 80bad143 869a24c0 011206d0 00a2de70 nt!ObpDecrementHandleCount+0x1fa
0f eef6acec 80bad344 e25fe548 00000000 00000430 nt!ObpCloseHandleTableEntry+0x1f3
10 eef6ad38 80bad4c3 00000430 00000001 00000000 nt!ObpCloseHandle+0xce
11 eef6ad4c 80ad5ae8 00000430 7c83d3bc 00000000 nt!NtClose+0x1d
12 eef6ad4c 7c90eb94 00000430 7c83d3bc 00000000 nt!KiFastCallEntry+0x158
WARNING: Stack unwind information not available. Following frames may be wrong.
13 0012f224 004017ed 00000430 00330030 00410a90 ntdll!KiFastSystemCallRet

Looks like you’re simulatenously trying to purge and copy to the section.
Have you looked at the other threads in the system to see if anyone is
currently calling CcPurgeCacheSection?

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
.

wrote in message news:xxxxx@ntfsd…
> Hi NTFSD,
>
>
> I am develpoing a file system driver. During some regression testing,I get
> this system ASSERT failure-
>
> Assertion failed: ControlArea->u.Flags.BeingPurged == 0
> Source File: d:\xpsprtm\base\ntos\mm\mapcache.c, line 166
>
> It occurs when I run an automation tool which performs almost all normal
> file operations( Create, Read, Write, query/set file/volume information
> etc) in an infinite fashion.
>
> If I ignore that ASSERT, it works fine, even with driver verifier enabled.
>
> But it looks something suspecious to me.
>
> Any insight on this ASSERT and its possible cause of failure?
> Details are below.
>
> ASSERT:
>
>
Assertion failed: ControlArea->u.Flags.BeingPurged == 0
> *** Source File: d:\xpsprtm\base\ntos\mm\mapcache.c, line 166
>
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread (boipt)? b
>
>
> STACK TRACE:
> # ChildEBP RetAddr Args to Child
> 00 eef6a7f0 80a9208c 80a91cdc 80a91cb8 000000a6 nt!RtlAssert+0x18
> 01 eef6a82c 80a18376 e128b430 869f81b0 eef6a858
> nt!MmMapViewInSystemCache+0x146
> 02 eef6a89c 80a18823 86689510 008dc000 00000000 nt!CcGetVacbMiss+0x304
> 03 eef6a8c8 80a12301 866895e0 008dc000 00000000
> nt!CcGetVirtualAddress+0xc9
> 04 eef6a958 80a0f00e 86689510 e27d4000 eef6a99c nt!CcMapAndCopy+0xe9
> 05 eef6a9e8 ee5b0981 865bc578 eef6aa2c 00001000 nt!CcCopyWrite+0x2a6
> 06 eef6aa54 ee5b5ceb 86575200 86617880 000008dc
> myFSD!UpdateNodeToCache+0x141
> 07 eef6aa68 ee5b5cbe ee18dee5 86617788 8bac4e70
> myFSD!UpdateINodeFromFcb+0x45b
> 08 eef6aad4 ee5cbfb7 86575200 861206e8 8a94ce90
> myFSD!UpdateINodeFromFcb+0x42e
> 09 eef6abd8 ee5cb5a2 86575200 8bac4e70 ee18d811 myFSD!CommonCleanup+0x997
> 0a eef6ac20 80a21a41 86617788 8bac4e70 86617788 myFSD!FsdCleanup+0xc2
> 0b eef6ac38 80cd4128 861206e8 8bac4e70 8bac4e80 nt!IopfCallDriver+0x51
> 0c eef6ac5c 80b3718b 80102524 86a2de70 86a2df04 nt!IovCallDriver+0xa0
> 0d eef6ac88 80badf1c 869a24c0 861206e8 00100081 nt!IopCloseFile+0x29d
> 0e eef6acc0 80bad143 869a24c0 011206d0 00a2de70
> nt!ObpDecrementHandleCount+0x1fa
> 0f eef6acec 80bad344 e25fe548 00000000 00000430
> nt!ObpCloseHandleTableEntry+0x1f3
> 10 eef6ad38 80bad4c3 00000430 00000001 00000000 nt!ObpCloseHandle+0xce
> 11 eef6ad4c 80ad5ae8 00000430 7c83d3bc 00000000 nt!NtClose+0x1d
> 12 eef6ad4c 7c90eb94 00000430 7c83d3bc 00000000 nt!KiFastCallEntry+0x158
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 13 0012f224 004017ed 00000430 00330030 00410a90 ntdll!KiFastSystemCallRet
>