Help with Deadlock

NTDEV
1

I understand most of my current issue, but I’m hoping to better understand things before deciding on a final solution or what steps to take next.

Essentially, our service is stuck on a Critical Section because multiple threads (This is expected and hence the Critical Section) are accessing the same file. However, one driver is not allowing our close handle of the file to complete, thus that thread never releases the Critical Section and the other thread just waits.

Now I realize that we could release the CS before closing the handle (We’re already done doing what we needed to do) and that would probably fix things, but I’m trying to understand why a driver is not letting our close complete. Here’s an output of the thread:

THREAD 85463db0 Cid 0ec4.00d4 Teb: 7ffac000 Win32Thread: 00000000 WAIT: (Unknown) KernelMode Non-Alertable
FreezeCount 1
f456d990 NotificationEvent
85463e28 NotificationTimer
IRP List:
851bd7f0: (0006,01d8) Flags: 00000404 Mdl: 00000000
Not impersonating
DeviceMap e1000178
Owning Process 85f9ca30 Image: PATSvc.exe
Attached Process N/A Image: N/A
Wait Start TickCount 21411786 Ticks: 1 (0:00:00:00.015)
Context Switch Count 5344409
UserTime 00:00:00.000
KernelTime 00:00:00.015
Win32 Start Address 0x0040b9a0
Start Address 0x77e617ec
Stack Init f456e000 Current f456d8c8 Base f456e000 Limit f456b000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0
ChildEBP RetAddr
f456d8e0 8082ffe5 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
f456d8f8 808287d4 nt!KiSwapThread+0x83 (FPO: [0,2,0])
f456d93c f4b4a46f nt!KeWaitForSingleObject+0x2e0 (FPO: [5,12,4])
WARNING: Stack unwind information not available. Following frames may be wrong.
f456d968 f4b4c3c0 mfehidk+0x46f
f456d9d4 f49d48c4 mfehidk+0x23c0
f456da80 f49d2d40 mfeavfk+0x38c4
f456db08 f4b56187 mfeavfk+0x1d40
f456db24 f4b519a0 mfehidk+0xc187
f456db9c f4b51baf mfehidk+0x79a0
f456dc30 f4b5fae6 mfehidk+0x7baf
f456dc40 f4b5fb36 mfehidk+0x15ae6
f456dc68 8081d5c3 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48
f456dc7c 808f1800 nt!IofCallDriver+0x45 (FPO: [0,0,4])
f456dcac 8092cab4 nt!IopCloseFile+0x2ae (FPO: [5,7,0])
f456dcdc 8092c3b5 nt!ObpDecrementHandleCount+0xcc (FPO: [4,2,4])
f456dd04 8092c44e nt!ObpCloseHandleTableEntry+0x131 (FPO: [5,1,0])
f456dd48 8092c56b nt!ObpCloseHandle+0x82 (FPO: [2,7,4])
f456dd58 80883968 nt!NtClose+0x1b (FPO: [1,0,0])
f456dd58 7c82847c nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f456dd64)
015fff04 00000000 0x7c82847c

We see the NtClose, and then finally the KeWaitForSingleObject. How can I find out what object it’s waiting on and then track that back to possibly another thread? Is it one of these objects?

f456d990 NotificationEvent
85463e28 NotificationTimer

I’ve tried various WinDbg commands, but nothing seemed to provide much detail that I can make sense of.

Here’s what !locks shows:

Resource @ 0x8546358c Exclusively owned
Threads: 85463db0-01<*>
KD: Scanning for held locks…
6366 total locks, 1 locks currently held

I’m sure a trained eye knows how to “connect the dots” so thanks in advance for any help.

2

xxxxx@yahoo.com wrote:

…
Essentially, our service is stuck on a Critical Section because multiple threads (This is expected and hence the Critical Section) are accessing the same file. However, one driver is not allowing our close handle of the file to complete, thus that thread never releases the Critical Section and the other thread just waits.

Now I realize that we could release the CS before closing the handle (We’re already done doing what we needed to do) and that would probably fix things, but I’m trying to understand why a driver is not letting our close complete. Here’s an output of the thread:
…
Priority 8 BasePriority 8 PriorityDecrement 0
ChildEBP RetAddr
f456d8e0 8082ffe5 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
f456d8f8 808287d4 nt!KiSwapThread+0x83 (FPO: [0,2,0])
f456d93c f4b4a46f nt!KeWaitForSingleObject+0x2e0 (FPO: [5,12,4])
WARNING: Stack unwind information not available. Following frames may be wrong.
f456d968 f4b4c3c0 mfehidk+0x46f
f456d9d4 f49d48c4 mfehidk+0x23c0
f456da80 f49d2d40 mfeavfk+0x38c4
f456db08 f4b56187 mfeavfk+0x1d40

mfehidk.sys and mfeavkf.sys are both part of McAfee antivirus. First,
try turning the antivirus off to see if that eliminates the problem.
After that, you may have to submit the dump to McAfee.

Good luck.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Yes, I have a contact with McAfee and I’ll discuss this more with them.

I hope to gain more knowledge with WinDbg though. We’ve atempted taking the OSR debugging class but was canceled due to lack of interest. We’ll see if the one in June gathers more interest.

I’m hoping to find out what commands will allow me to see what the KeWaitForSingleObject is waiting on and then perhaps tracking that back to another thread.

Thanks for any input.

4

Oh and sorry, this was suppose to go to the WinDbg list.