Crash Dump Analysis Patterns (Part 290)
Wednesday, March 13th, 2024If we look at memory values in a thread stack region we see they are either come from the stack or some other non-stack region, such as heap, pool, or just some static code or data location. What is quite unusual is when such value belongs to another thread stack:
0:004> ~0e !teb
TEB at 00000055ad63d000
ExceptionList: 0000000000000000
StackBase: 00000055ad900000
StackLimit: 00000055ad8fd000
SubSystemTib: 0000000000000000
FiberData: 0000000000001e00
ArbitraryUserPointer: 0000000000000000
Self: 00000055ad63d000
EnvironmentPointer: 0000000000000000
ClientId: 00000000000035c4 . 0000000000005fa4
RpcHandle: 0000000000000000
Tls Storage: 000001c2e6269540
PEB Address: 00000055ad63c000
LastErrorValue: 0
LastStatusValue: c0000034
Count Owned Locks: 0
HardErrorMode: 0
0:004> ~3e !teb
TEB at 00000055ad643000
ExceptionList: 0000000000000000
StackBase: 00000055adc00000
StackLimit: 00000055adbfe000
SubSystemTib: 0000000000000000
FiberData: 0000000000001e00
ArbitraryUserPointer: 0000000000000000
Self: 00000055ad643000
EnvironmentPointer: 0000000000000000
ClientId: 00000000000035c4 . 0000000000005f1c
RpcHandle: 0000000000000000
Tls Storage: 000001c2e62714b0
PEB Address: 00000055ad63c000
LastErrorValue: 187
LastStatusValue: c000000d
Count Owned Locks: 0
HardErrorMode: 0
0:004> dps 00000055adbfe000 00000055adc00000
00000055`adbfe000 00000000`00000000
00000055`adbfe008 00000000`00000000
00000055`adbfe010 00000000`00000000
00000055`adbfe018 00000000`00000000
00000055`adbfe020 00000000`00000000
…
00000055`adbffa58 00000000`00000008
00000055`adbffa60 00000055`adbffb28
00000055`adbffa68 00007ff7`96e116a3 module!func+0×13
00000055`adbffa70 00000055`ad8ffde0
00000055`adbffa78 00000000`00000000
00000055`adbffa80 00000000`00000000
00000055`adbffa88 00007ffa`28ecc9a8 ucrtbase!`string’
00000055`adbffa90 00000000`00000000
00000055`adbffa98 00007ff7`96e116c3 module!thread_proc+0×13
00000055`adbffaa0 00000055`ad8ffde0
00000055`adbffaa8 00000055`adbffb28
00000055`adbffab0 ffffffff`ffffffff
00000055`adbffab8 00007ffa`28fa0748 KERNELBASE!GetAppModelPolicy+0×18
00000055`adbffac0 00000055`adbffba0
00000055`adbffac8 00007ff7`96e12657 module!std::invoke<void (__cdecl*)(int *),int *>+0×27
00000055`adbffad0 00000055`ad8ffde0
00000055`adbffad8 00000055`adbffb00
00000055`adbffae0 00000055`adbffb18
…
Such Foreign Stack references in user space may point to possibly questionable use of pointers to local variables in asynchronous scenarios. In kernel space, !findthreads WinDbg command may find values from the kernel stack of the specified thread address on other thread kernel stacks even from different processes. Such references may also reveal deep process and thread relationships in kernel.
- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -