Sometimes Wait Chains (Volume 1, page 482) such as involving critical sections (Volume 1, page 490) may have a Missing Thread (Volume 1, page 362) endpoint. However, in some cases we might see a Ghost Thread whose TID was reused by subsequent thread creation in a different process. For example, critical section structure may refer to such TID as in the example below.
// Critical section from LSASS process THREAD fffffa803431cb50 Cid 03e8.2718 Teb: 000007fffff80000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable fffffa80330e0500 SynchronizationEvent Impersonation token: fffff8a00b807060 (Level Impersonation) Owning Process fffffa8032354c40 Image: lsass.exe Attached Process N/A Image: N/A Wait Start TickCount 107175 Ticks: 19677 (0:00:05:06.963) Context Switch Count 2303 IdealProcessor: 1 UserTime 00:00:00.218 KernelTime 00:00:00.109 Win32 Start Address ntdll!TppWorkerThread (0×0000000076e1f2e0) Stack Init fffff88008e5fdb0 Current fffff88008e5f900 Base fffff88008e60000 Limit fffff88008e5a000 Call 0 Priority 10 BasePriority 10 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5 Kernel stack not resident. Child-SP RetAddr Call Site fffff880`08e5f940 fffff800`01c7cf72 nt!KiSwapContext+0×7a fffff880`08e5fa80 fffff800`01c8e39f nt!KiCommitThreadWait+0×1d2 fffff880`08e5fb10 fffff800`01f7fe3e nt!KeWaitForSingleObject+0×19f fffff880`08e5fbb0 fffff800`01c867d3 nt!NtWaitForSingleObject+0xde fffff880`08e5fc20 00000000`76e5067a nt!KiSystemServiceCopyEnd+0×13 (TrapFrame @ fffff880`08e5fc20) 00000000`0427cca8 00000000`76e4d808 ntdll!NtWaitForSingleObject+0xa 00000000`0427ccb0 00000000`76e4d6fb ntdll!RtlpWaitOnCriticalSection+0xe8 00000000`0427cd60 000007fe`f46a4afe ntdll!RtlEnterCriticalSection+0xd1 [...] 1: kd> .process /r /p fffffa8032354c40 Implicit process is now fffffa80`32353b30 Loading User Symbols 1: kd> !cs -l -o -s ----------------------------------------- DebugInfo = 0x0000000003475220 Critical section = 0x0000000003377740 (+0x3377740) LOCKED LockCount = 0×10 WaiterWoken = No OwningThread = 0×00000000000004e4 RecursionCount = 0×0 LockSemaphore = 0×0 SpinCount = 0×0000000000000000 OwningThread = .thread fffffa80344e4c00 [...] // The "owner" thread is from winlogon.exe 1: kd> !thread fffffa80344e4c00 3f THREAD fffffa80344e4c00 Cid 21d0.14e4 Teb: 000007fffffae000 Win32Thread: fffff900c0998c20 WAIT: (WrUserRequest) UserMode Non-Alertable fffffa80355817d0 SynchronizationEvent Not impersonating DeviceMap fffff8a0000088f0 Owning Process fffffa8034ff77c0 Image: winlogon.exe [...]
A PML (Process Monitor) log was recorded before the complete memory dump was forced, and it clearly shows Glued Activity (Volume 6, page 250) trace analysis pattern. LSASS owned the thread but then the thread exited, and 2 other processes subsequently reused its TID.
18.190.217.139