Could anybody help me understand what is indeed going on with my case?
My filter implements CACHE_MANAGER_CALLBACKS callback routines and initializes the cache for FOs.
In this BSOD AcquireForReadAhead and ReleaseFromReadAhead are in concern.
In AcquireForReadAhead implementation I am taking the FO’s FCB resource shared (ExAcquireResourceExclusiveLite(pFCB->Resource, Wait)) and then releasing it in ReleaseFromReadAhead (ExReleaseResourceLite( pFCB->Resource )).
In addition, I am taking the resource also during cached reads (ExAcquireResourceSharedLite(pFCB->Resource, TRUE)) prior directly invoking CcCopyRead.
So BSOD is observed when cached read intesects with Cache Manager’s ReadAhead callbacks:
- Cached read takes the resource and calls CcCopyRead.
- At that moment CcPerformReadAhead from Cc worker thread invokes my AcquireForReadAhead callback, does the job, and then invokes ReleaseFromReadAhead routine which results in E3 BugCheck which says that the thread does not own the resource.
I also have seen the case where the same happens with cached read thread when by time it tries to release the shared resource (if read ahead took place in the middle) it ends up with the same BugCheck. Am I missing anything with organizing ERESOURCE shared locks?
----Some WinDbg details
ESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: fffffa8002d92af0, Address of resource
Arg2: fffffa8000cb4b60, Address of thread
Arg3: fffffa8002c7e2f0, Address of owner table if there is one
Arg4: 0000000000000003
…
kd> !locks -v fffffa8002d92af0
Resource @ 0xfffffa8002d92af0 Shared 2 owning threads
Threads: fffffa8002a9cb63-01<*> *** Actual Thread fffffa8002a9cb60
THREAD fffffa8002a9cb60 Cid 09b8.09bc Teb: 000007fffffde000 Win32Thread: fffff900c26c1850 ???
IRP List:
fffffa8000d92010: (0006,03e8) Flags: 00060900 Mdl: fffffa8002267970
Not impersonating
DeviceMap fffff8a00085c0d0
Owning Process 0 Image:
Attached Process fffffa80026414f0 Image: hh.exe
Wait Start TickCount 9041 Ticks: 1 (0:00:00:00.015)
Context Switch Count 71 LargeStack
UserTime 00:00:00.046
KernelTime 00:00:00.593
Win32 Start Address 0x00000000ff0e1d30
Stack Init fffff880045cadb0 Current fffff880045ca400
Base fffff880045cb000 Limit fffff880045c2000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
fffff880045ca440 fffff800026d428e nt!KiSwapContext+0x7a
fffff880045ca580 fffff800026d3f24 nt!KiExitDispatcher+0x21e
fffff880045ca5f0 fffff800026cfb84 nt!KiInsertQueue+0x1b4
fffff880045ca680 fffff800026a2d27 nt!ExQueueWorkItem+0x44
fffff880045ca6c0 fffff80002678f6d nt!CcPostWorkQueue+0x87
fffff880045ca6f0 fffff8000296eb4f nt!CcScheduleReadAhead+0x3fd
fffff880045ca790 fffff88000e21a76 nt!CcCopyRead+0x26f
…
fffffa8000cb4b63-01<> Actual Thread fffffa8000cb4b60
THREAD fffffa8000cb4b60 Cid 0004.0020 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
DeviceMap fffff8a000008bb0
Owning Process 0 Image:
Attached Process fffffa8000c9e040 Image: System
Wait Start TickCount 9042 Ticks: 0
Context Switch Count 318
UserTime 00:00:00.000
KernelTime 00:00:00.062
Win32 Start Address nt!ExpWorkerThread (0xfffff800026d4630)
Stack Init fffff88002f2adb0 Current fffff88002f2a580
Base fffff88002f2b000 Limit fffff88002f25000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
fffff88002f2a2c8 fffff800027b2792 nt!RtlpBreakWithStatusInstruction
fffff88002f2a2d0 fffff800027b357e nt!KiBugCheckDebugBreak+0x12
fffff88002f2a330 fffff800026cf084 nt!KeBugCheck2+0x71e
fffff88002f2aa00 fffff8000271cead nt!KeBugCheckEx+0x104
fffff88002f2aa40 fffff88000e274fd nt! ?? ::FNODOBFM::string'+0x197d4<br> fffff88002f2aaa0 fffff8000266b2a3 ProtectF!SxpReleaseReadAhead+0x6d<br> fffff88002f2aae0 fffff800026c0c22 nt!CcPerformReadAhead+0x613<br> fffff88002f2ac00 fffff800026d4744 nt!CcWorkerThread+0x21e<br> fffff88002f2acb0 fffff80002954e66 nt!ExpWorkerThread+0x11a<br> fffff88002f2ad40 fffff80002681a86 nt!PspSystemThreadStartup+0x5a<br> fffff88002f2ad80 00000000`00000000 nt!KxStartSystemThread+0x16
1 total locks, 1 locks currently held
…
kd> !locks
DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…
Resource @ 0xfffffa80025d29d8 Shared 1 owning threads
Threads: fffffa80029c3b60-01<>
KD: Scanning for held locks…
Resource @ 0xfffffa800272b6f0 Shared 1 owning threads
Threads: fffffa8002a1db60-01<>
KD: Scanning for held locks…
Resource @ 0xfffffa8002d92af0 Shared 2 owning threads
Threads: fffffa8002a9cb63-01<>** Actual Thread fffffa8002a9cb60
fffffa8000cb4b63-01<*> *** Actual Thread fffffa8000cb4b60
KD: Scanning for held locks…
4550 total locks, 3 locks currently held
-----------------------
Will KeEnterCriticalRegion in cache manager’s callback routines be in any help?
Any quick hints will be greatly appreciated.
Thanks,
Tigran