Archive for September, 2021

Crash Dump Analysis Patterns (Part 277)

Monday, September 27th, 2021

When looking at the kernel and complete memory dumps, the current thread running on the current processor (!thread) may not belong to the current process (not listed in the output of !process WinDbg command). This observation happens when a thread that is owned by one process gets attached to the second process:

0: kd> !thread
THREAD ffffa902d2ff8080 Cid 1f00.02c0 Teb: 000000836c677000 Win32Thread: 0000000000000000 RUNNING on processor 0
IRP List:
ffffa902d0afabb0: (0006,0118) Flags: 00060000 Mdl: 00000000
Not impersonating
DeviceMap ffffba81b0037600
Owning Process ffffa902d1581080 Image: OriginalProcess.exe
Attached Process ffffa902cf41a080 Image: NewProcess.exe
Wait Start TickCount 136814 Ticks: 3 (0:00:00:00.046)
Context Switch Count 4 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:00.046
Win32 Start Address 0×00007ff62aabf010
Stack Init ffffe10adff87c90 Current ffffe10adff876a0
Base ffffe10adff88000 Limit ffffe10adff82000 Call 0000000000000000
Priority 14 BasePriority 8 PriorityDecrement 80 IoPriority 2 PagePriority 5
[…]

In this way, a thread can access another process space. We call such analysis pattern Shared Thread. Another example is process creation resulting in Hidden Process. Such Shared Threads can also be found in Stack Trace Collection.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Trace Analysis Patterns (Part 212)

Saturday, September 11th, 2021

Even if traces and logs are perfectly synchronized (Unsynchronized Traces) we me still get Unsynchronized Messages. If respective message times are the same (can depend on time resolution) we don’t know which one was first. This is visible if we do Trace Mask using different order:

If both messages belong to the same Thread of Activity we may be able to reorder them correctly based on additional message semantics, such as module hierarchy (for example, OS runtime library and application code that are traced separately).

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -