!logon command?

WINDBG
1

I saw an analysis from someone at Microsoft which used the “!logon” extension, specifically “!logon -a”. Does anyone know where that extension comes from? It’s not part of MEX, and a Google search didn’t turn up anything (though you cannot search with the “!”, so it may be hidden somewhere). (I hope I’m not just being stupid.)

2

I don’t see it listed in any of the extension DLL exports (only !logonsession). What does the output look like?

3

Thanks for your interest. I should have posted this the first time around; silly me. The “Stuck Winlogon … Performing wait chain analysis” is the key bit that I’m after since it’s surely the signature of the issue that I’m chasing. Perhaps there’s some other way to do a similar thing?

kd> !logon -a
Winlogons found: 2

Stuck Winlogon a22ad8a8 in session 2. Performing wait chain analysis...
# Process                      Thread   State   Time            Reason         Function                                                    Target
= ============================ ======== ======= =============== ============== =========================================================== ========
1 winlogon.exe                 84f7f4b0 Waiting      29m:38.312 WrLpcReply     WINSTA!RpcConnectTerminal                                   a67ad228
2 lsm.exe                      a67ad228 Waiting      29m:37.531 WrLpcReply     ole32!ThreadSendReceive                                     aaad8030
3 svchost.exe (NetworkService) aaad8030 Waiting      29m:37.531 WrLpcReply     ADVAPI32!ROpenSCManagerW                                    840b28e8
4 services.exe                 840b28e8 Waiting      29m:37.515 UserRequest    services!CServiceRecordSharedLock::CServiceRecordSharedLock b16f6d10
5 services.exe                 b16f6d10 Waiting 2d.16:25:51.531 Executive      nt!IopUnloadDriver                                          8358fad0
6 System                       8358fad0 Waiting              0s DelayExecution nt!CmUnRegisterCallback         

Last thread in wait chain:

Process           Thread   CID       UserTime KernelTime ContextSwitches Wait Reason    Time State
System (83589558) 8358fad0 4.4c            0s  2m:48.359       238217533 DelayExecution   0s Waiting

# Child-SP Return   Call Site                           
0 8713fb5c 81e871d9 nt!KiSwapContext+0x26               
1 8713fb70 81e7e884 nt!KiSwapThread+0x44f               
2 8713fbb4 81f90d32 nt!KeDelayExecutionThread+0x472     
3 8713fc10 8d8fe091 nt!CmUnRegisterCallback+0x182       
4 8713fc84 8d8044da BHDrvx86+0xfd091 >>>>>>>>>>>>
5 8713fcb8 8d80226a BHDrvx86+0x34da 
6 8713fcd4 8d8021ed BHDrvx86+0x126a 
7 8713fcf0 8d8028ef BHDrvx86+0x11ed 
8 8713fcfc 81fda502 BHDrvx86+0x18ef 
9 8713fd0c 81f0fcaf nt!IopLoadUnloadDriver+0x1e         
a 8713fd4c 8207c642 nt!ExpWorkerThread+0xfd             
b 8713fd84 81f2a9e2 nt!PspSystemThreadStartup+0x114     
c 8713fdc8 00000000 nt!KiThreadStartup+0x16
4

Definitely don’t see that command anywhere. That wait chain analysis is pretty cool though, I wonder if it relies on private PDBs.

I think you should be able to do most of this manually with !process and !thread though. Are you having a problem with winlogon hanging?

5

i dont think private pdbs are needed this is probably based on wct apis GetThreadWaitChain() implementation there is a sample code that uses this api in ms docs i also remember sasha ( goldshtn ) had written one wct extension

6

Thanks for the suggestion. I tried the WCT WinDbg extension, but unfortunately, it seems to only work for live debugging, not a memory dump.