Hi (sorry for my english, not a native speaker), we've got a deadlock problem on our customers PC's with symantec antivirus (probably together with our driver).
All 3 manual BSODs show us that there are 2 (or more) threads (holding other resources) waiting for one resource:
for instance:
Resource @ 0x82d07514 Shared 1 owning threads
Contention Count = 471
NumberOfSharedWaiters = 24
NumberOfExclusiveWaiters = 1
Threads: 82dc7698-01<*> fe70d668-01 fe2eb418-01 82dc5020-01
81f36af0-01 82115450-01 fe5b7da8-01 8237ca00-01
8237eda8-01 820bb690-01 fe810348-01 fe683548-01
81f51ba0-01 fe6eab30-01 820d6bb0-01 82159580-01
82dc7b88-01 8235c020-01 ffa5b020-01 ffb6fda8-01
8212db30-01 fe7d7020-01 fe7cfda8-01 fe1ed560-01
fe6692c0-01
Threads Waiting On Exclusive Access:
82dc63c8
Thread holding this resource (in this case 82dc7698) always looks similar to this:
0: kd> !thread 82dc7698
THREAD 82dc7698 Cid 0004.0018 Teb: 00000000 Win32Thread: 00000000 WAIT: (Spare6) KernelMode Non-Alertable
f89b9aa4 SynchronizationEvent
Not impersonating
DeviceMap e1000988
Owning Process 82dc8660 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 33631 Ticks: 24984 (0:00:06:30.375)
Context Switch Count 10697
UserTime 00:00:00.000
KernelTime 00:00:00.203
Start Address nt!ExpWorkerThread (0x8053868e)
Stack Init f89ba000 Current f89b9a30 Base f89ba000 Limit f89b7000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 1 DecrementCount 16
ChildEBP RetAddr Args to Child
f89b9a48 80503846 82dc7708 82dc7698 804fb078 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
f89b9a54 804fb078 a527cf6c 00000000 00000002 nt!KiSwapThread+0x8a (FPO: [0,0,0])
f89b9a7c f82c8d9c 00000000 00000019 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f89b9ac8 f82c617e f89b9ae0 a52860d2 a527cf6c fltmgr!FltpExfAcquirePushLockExclusive+0x78 (FPO: [Non-Fpo])
f89b9ad0 a52860d2 a527cf6c 8229c0d0 f89b9af8 fltmgr!FltAcquirePushLockExclusive+0x20 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
f89b9ae0 f82c2f24 fe6273a0 fe6273a0 00000000 SRTSP+0x160d2
f89b9af8 f82c308b fe627378 fe627378 f89b9b20 fltmgr!DoFreeContext+0x20 (FPO: [Non-Fpo])
f89b9b08 f82cdc72 fe627378 fe695d28 fe695d50 fltmgr!DoReleaseContext+0x25 (FPO: [Non-Fpo])
f89b9b20 f82d89f3 fe695d88 fe695d50 ffffffff fltmgr!FltpDeleteContextList+0x7c (FPO: [Non-Fpo])
f89b9b40 f82d8c3d fe695d28 e1be0650 fe695d2c fltmgr!CleanupStreamListCtrl+0x1b (FPO: [Non-Fpo])
f89b9b58 8056ea58 fe695d2c 00000000 f89b9be0 fltmgr!DeleteStreamListCtrlCallback+0x61 (FPO: [Non-Fpo])
f89b9ba0 f824a163 e1be0650 e1be0588 e1be0650 nt!FsRtlTeardownPerStreamContexts+0x52 (FPO: [Non-Fpo])
f89b9bbc f8232e30 8235cc78 f89b0705 e1be05b8 Ntfs!NtfsDeleteScb+0x165 (FPO: [Non-Fpo])
f89b9bd4 f820d7f4 8235cc78 e1be0650 00000000 Ntfs!NtfsRemoveScb+0x88 (FPO: [Non-Fpo])
f89b9bf0 f8232c17 8235cc78 e1be0588 00000000 Ntfs!NtfsPrepareFcbForRemoval+0x52 (FPO: [Non-Fpo])
f89b9c38 f820d7a4 8235cc78 e1be0650 00000000 Ntfs!NtfsTeardownStructures+0x5b (FPO: [Non-Fpo])
f89b9c64 f82306b5 8235cc78 00be0650 00000000 Ntfs!NtfsDecrementCloseCounts+0x9e (FPO: [Non-Fpo])
f89b9ce8 f82355e3 8235cc78 e1be0650 e1be0588 Ntfs!NtfsCommonClose+0x398 (FPO: [Non-Fpo])
f89b9d7c 8053877d 00000000 00000000 82dc7698 Ntfs!NtfsFspClose+0xe3 (FPO: [Non-Fpo])
f89b9dac 805cff70 00000000 00000000 00000000 nt!ExpWorkerThread+0xef (FPO: [Non-Fpo])
f89b9ddc 805460ee 8053868e 00000000 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
So, thread x82dc7698 holding "critical" resource is waiting for some PushLock and the waiting was initiated by SRTSP.
Our driver (not in thread stack right now, but sometime does), does some restrictive actions on file-system (for instance: sends ACCESS_DENIED when user want to open file he's not allowed to (on FAt or USB flashdrive) ). So maybe we caused this deadlock, but I've got no clue how to find out how.
I googled that SRTSP.sys is driver connected with symantec antivirus and the version looks new to me (a5270000 a52ba000 SRTSP Tue Aug 11 05:20:28 2009 (4A80E37C)).
Has anyone met such behavior as well?
Or, is here anyone connected with SRTSP.sys who can tell me whats the driver waiting for? :)
Thanks
Roman