The driver is file system.
In some situation, when calling the CcPurgeCacheSection() from Cleanup
dispatch entry, the call blocks.
Before calling the interface FileObject resources are acquired exclusively.
The first thought was that it could be a deadlock caused by corrupted
locking hierarchy, but it wasn’t.
( WinDbg !locks does not list any exclusive waiters)
In fact CcPurgeCacheSection(), calls MmPurgeSection(), which fails because
FileObject->SectionObjectPointers->DataSectionObject->NumberOfSystemCacheVie
ws != 0.
After some fixed delay it tries again, and this loop never ends.
I couldn’t identify the conditions on which the problem occures. I have seen
other requests with NumberOfSystemCacheViews!=0 and after the call it
becomes zero.
Any idea why this happens?
May be I have to make the asynchronous purge from a system thread?
Kristian
Debug info:
0: kd> kb
*** Stack trace for last set context - .thread resets it
ChildEBP RetAddr Args to Child
b863da54 8042bec0 00000000 812280a8 00000000 nt!KiSwapThread+0x1b1
b863da7c 80411463 00000000 00000000 8046ec10 nt!KeDelayExecutionThread+0x182
b863dae0 bfa563ec 81214f90 00000000 00000000 nt!CcPurgeCacheSection+0x131
b863db00 bfa579e1 811e8e08 8135e018 811ccbc8 TESTFS!TfsPurgeFile+0xc96
b863dbdc bfa5a837 8135e018 811ccbc8 00000012 TESTFS!TfsCleanup
(TESTFS+0x59e1)
b863dc30 8041de73 8135e018 811ccbc8 811e8e08 TESTFS!TfsCommonDispatch+0xf2c
b863dc68 80492676 8041515f 80065018 b863dca4 nt!IopfCallDriver+0x35
b863dc78 804d95cd 812611a0 8135e018 00120089 nt!ExDestroyHandle+0xc0
b863dca4 80450072 812611a0 811e8df4 811e8e08
nt!ObpDecrementHandleCount+0x13d
b863dd58 804668a9 00002ae0 80065101 bf9eec78 nt!NtClose+0x1f0
b863dd58 77f828d3 00002ae0 80065101 bf9eec78 nt!KiSystemService+0xc9
0111a9f4 00000000 00000000 00000000 00000000 0x77f828d3
0: kd> dt _FILE_OBJECT 0x811E8E08
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x81671ef0
+0x008 Vpb : 0x813b8de8
+0x00c FsContext : 0x81214f68
+0x010 FsContext2 : 0x8127c7e8
+0x014 SectionObjectPointer : 0x81214f90
+0x018 PrivateCacheMap : 0x81228178
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0xc0002
+0x030 FileName : _UNICODE_STRING “\image\tga01_00000.tga”
+0x038 CurrentByteOffset : _LARGE_INTEGER 12
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)
0: kd> dt _SECTION_OBJECT_POINTERS 0x81214f90
+0x000 DataSectionObject : 0x811442c8
+0x004 SharedCacheMap : 0x812280a8
+0x008 ImageSectionObject : (null)
0: kd> dt _CONTROL_AREA 0x811442C8
+0x000 Segment : 0xe2a1d408
+0x004 DereferenceList : _LIST_ENTRY [0x0 - 0x0]
+0x00c NumberOfSectionReferences : 1
+0x010 NumberOfPfnReferences : 0x11
+0x014 NumberOfMappedViews : 1
+0x018 NumberOfSubsections : 1
+0x01a FlushInProgressCount : 0
+0x01c NumberOfUserReferences : 0
+0x020 u : __unnamed
+0x024 FilePointer : 0x811e8e08
+0x028 WaitingForDeletion : (null)
+0x02c ModifiedWriteCount : 0
+0x02e NumberOfSystemCacheViews : 1
+0x030 PagedPoolUsage : 0x760
+0x034 NonPagedPoolUsage : 0x80
This is typically caused by a race where a system cache view was mapped
after CcPurgeCacheSection had unmapped all its views but before it had
called MmPurgeSection. The cache manager relies on the file system to
synchronize the call to CcPurgeCacheSection with all other paths through
the file system which could result in a view getting mapped.
Regards,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kristian Traikov
Sent: Wednesday, November 24, 2004 1:43 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] CcPurgeCacheSection enters the infinite loop
The driver is file system.
In some situation, when calling the CcPurgeCacheSection() from Cleanup
dispatch entry, the call blocks.
Before calling the interface FileObject resources are acquired
exclusively.
The first thought was that it could be a deadlock caused by corrupted
locking hierarchy, but it wasn’t.
( WinDbg !locks does not list any exclusive waiters)
In fact CcPurgeCacheSection(), calls MmPurgeSection(), which fails
because
FileObject->SectionObjectPointers->DataSectionObject->NumberOfSystemCach
FileObject->SectionObjectPointers->DataSectionObject->eVie
ws != 0.
After some fixed delay it tries again, and this loop never ends.
I couldn’t identify the conditions on which the problem occures. I have
seen other requests with NumberOfSystemCacheViews!=0 and after the call
it becomes zero.
Any idea why this happens?
May be I have to make the asynchronous purge from a system thread?
Kristian
Debug info:
0: kd> kb
*** Stack trace for last set context - .thread resets it ChildEBP
RetAddr Args to Child
b863da54 8042bec0 00000000 812280a8 00000000 nt!KiSwapThread+0x1b1
b863da7c 80411463 00000000 00000000 8046ec10
nt!KeDelayExecutionThread+0x182 b863dae0 bfa563ec 81214f90 00000000
00000000 nt!CcPurgeCacheSection+0x131 b863db00 bfa579e1 811e8e08
8135e018 811ccbc8 TESTFS!TfsPurgeFile+0xc96 b863dbdc bfa5a837 8135e018
811ccbc8 00000012 TESTFS!TfsCleanup
(TESTFS+0x59e1)
b863dc30 8041de73 8135e018 811ccbc8 811e8e08
TESTFS!TfsCommonDispatch+0xf2c
b863dc68 80492676 8041515f 80065018 b863dca4 nt!IopfCallDriver+0x35
b863dc78 804d95cd 812611a0 8135e018 00120089 nt!ExDestroyHandle+0xc0
b863dca4 80450072 812611a0 811e8df4 811e8e08
nt!ObpDecrementHandleCount+0x13d
b863dd58 804668a9 00002ae0 80065101 bf9eec78 nt!NtClose+0x1f0
b863dd58 77f828d3 00002ae0 80065101 bf9eec78 nt!KiSystemService+0xc9
0111a9f4 00000000 00000000 00000000 00000000 0x77f828d3
0: kd> dt _FILE_OBJECT 0x811E8E08
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x81671ef0
+0x008 Vpb : 0x813b8de8
+0x00c FsContext : 0x81214f68
+0x010 FsContext2 : 0x8127c7e8
+0x014 SectionObjectPointer : 0x81214f90
+0x018 PrivateCacheMap : 0x81228178
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0xc0002
+0x030 FileName : _UNICODE_STRING “\image\tga01_00000.tga”
+0x038 CurrentByteOffset : _LARGE_INTEGER 12
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)
0: kd> dt _SECTION_OBJECT_POINTERS 0x81214f90
+0x000 DataSectionObject : 0x811442c8
+0x004 SharedCacheMap : 0x812280a8
+0x008 ImageSectionObject : (null)
0: kd> dt _CONTROL_AREA 0x811442C8
+0x000 Segment : 0xe2a1d408
+0x004 DereferenceList : _LIST_ENTRY [0x0 - 0x0]
+0x00c NumberOfSectionReferences : 1
+0x010 NumberOfPfnReferences : 0x11
+0x014 NumberOfMappedViews : 1
+0x018 NumberOfSubsections : 1
+0x01a FlushInProgressCount : 0
+0x01c NumberOfUserReferences : 0
+0x020 u : __unnamed
+0x024 FilePointer : 0x811e8e08
+0x028 WaitingForDeletion : (null)
+0x02c ModifiedWriteCount : 0
+0x02e NumberOfSystemCacheViews : 1
+0x030 PagedPoolUsage : 0x760
+0x034 NonPagedPoolUsage : 0x80
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com