Software Diagnostics Library

Trace Analysis Patterns (Part 257)

Dmitry Vostokov — Sun, 08 Mar 2026 19:43:20 +0000

Trace Network is an analysis pattern in which traces and logs are treated as evidence for constructing an attributed interaction network N=(V, E), where vertices V are Motives, (Adjoint) Threads or Features of Activity, and their combinations, and directed edges E are created by an explicit correspondence rule between them, for example, request/response, causality, correlation propagation, spawn/join relation, or shared resource usage. A scope such as Time Delta or some filtering for Message Patterns may also be applied before the network construction.

Edge aggregation, weighting, and labels are part of the construction specification, so the result is not merely a drawing but a diagnostic network on which structural properties such as fan-in, fan-out, hubs, components, and derived measures such as Trace Divergence can be computed. This differs from Trace Graph, whose primary purpose is plotting or graphing trace data, and from Message Complex, whose primary elements are messages connected geometrically rather than identities connected relationally.

Trace Network analysis pattern differs from Causal History, Causal Messages, and Causal Chains in both primitive elements and construction intent. Causal History is a message-level structure whose arrows represent possible causation; Causal Messages are those messages selected as causally relevant within that history; and Causal Chains are abstractions of causal relations into linked 1-chains, 2-chains, and higher n-chains. By contrast, Trace Network is a general constructed network whose vertices are typically diagnostic identities rather than messages, and whose edges are induced by an explicitly declared relation derived from trace evidence, such as causal linkage, adjoint correspondence, request/response coupling, shared-resource mediation, or correlation transfer. Accordingly, a Trace Network may encode causal structure as one special case, but it is not restricted to causality and does not by itself imply chain-complex abstraction.

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

Trace Analysis Patterns (Part 256)

Dmitry Vostokov — Sat, 28 Feb 2026 21:49:53 +0000

Sometimes, we want to count the number of (Adjoint) Threads of Activity corresponding to a specified ATID:

We can view this as (adjoint) threads coming into or out of the specified ATID, similar to divergence, which gives the name Trace Divergence log analysis pattern. This analysis pattern differs from Cord of Activity, which is not a number, and the latter may not have a single, unvarying source or target ATID to which other A(TID)s correspond. It is also different from Trace Flux, where the number of threads is an external variable not related to traces and logs, and from Message Flow, which operates on the individual message level, temporal in nature, and counters are set in advance.

Typical examples include SYN floods in network traces (src and dst ATIDs), the number of threads corresponding to the specific PID, or the number of threads contending for the specified API.

Activity Divergence may look similar, but its surface is temporal, whereas Trace Divergence’s, surface is structural. There can be several Trace Divergencies in the same trace or log since they are per ATID.

Formally, Trace Divergence is a property of a constructed graph, for example, D_in(a)=∣{x∈V∣x→a}∣; Activity Divergence is a property of a constructed signal, interpreted as dynamics, for example, D_in(a,t).

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

Crash Dump Analysis Patterns (Part 305)

Dmitry Vostokov — Fri, 09 Jan 2026 12:12:02 +0000

In ARM64 Virtualized Process memory dumps, their Stack Trace Collections, and their Execution Residue we may see pointers that point to ISA-Specific Code. For example, in an x86 process thread stack we may see this x86 disassembly of code pointers:

0:001> u 7573e81c kernel32!BaseThreadInitThunk+0x2c: 7573e81c 2808 sub byte ptr [eax],cl 7573e81e 0090083142b9 add byte ptr [eax-46BDCEF8h],dl 7573e824 e003 loopne kernel32!BaseThreadInitThunk+0x39 (7573e829) 7573e826 002a add byte ptr [edx],ch 7573e828 0001 add byte ptr [ecx],al 7573e82a 3f aas 7573e82b d6 ??? 7573e82c 2808 sub byte ptr [eax],cl

0:001> u 76e12640 KERNELBASE!SetEvent: 76e12640 fd std 76e12641 7bbe jnp KERNELBASE!UnmapViewOfFile+0x11 (76e12601) 76e12643 29fd sub ebp,edi 76e12645 0300 add eax,dword ptr [eax] 76e12647 91 xchg eax,ecx 76e12648 6810009008 push 8900010h 76e1264d a5 movs dword ptr es:[edi],dword ptr [esi] 76e1264e 43 inc ebx

0:001> ub 76e0c11c ^ Unable to find valid previous instruction for 'ub 76e0c11c'

0:001> ub 5f82d9c9 ACE!ACEInitializeEx+0x65573: 5f82d9b7 c3 ret 5f82d9b8 56 push esi 5f82d9b9 57 push edi 5f82d9ba 8b3da8b0835f mov edi,dword ptr [ACE!ACEInitializeEx+0x72c64 (5f83b0a8)] 5f82d9c0 8bf1 mov esi,ecx 5f82d9c2 6aff push 0FFFFFFFFh 5f82d9c4 ff7610 push dword ptr [esi+10h] 5f82d9c7 ffd7 call edi

0:001> ub ntdll!NtWaitForSingleObject+0xc ntdll!NtMapUserPhysicalPagesScatter: 779fd030 b803000a00 mov eax,0A0003h 779fd035 ba70a6a077 mov edx,offset ntdll!Wow64SystemServiceCall (77a0a670) 779fd03a ffd2 call edx 779fd03c c20c00 ret 0Ch 779fd03f 90 nop ntdll!NtWaitForSingleObject: 779fd040 b804000d00 mov eax,0D0004h 779fd045 ba70a6a077 mov edx,offset ntdll!Wow64SystemServiceCall (77a0a670) 779fd04a ffd2 call edx

The first 3 look like Wild Code (or Coincidental Symbolic Information if we use function names). But if we switch to CHPE architecture, we get the inverse, the first 3 right and the last 2 invalid:

0:001> .effmach CHPE Effective machine: CHPE on X86 (read only) (CHPE)

0:001:CHPE> u 7573e81c kernel32!BaseThreadInitThunk+0x2c: 7573e81c 90000828 adrp x8,kernel32!_imp_#LdrQueryImageFileKeyOption (75842000) 7573e820 b9423108 ldr w8,[x8,#0x230] 7573e824 2a0003e0 mov w0,w0 7573e828 d63f0100 blr x8 7573e82c 90000828 adrp x8,kernel32!_imp_#LdrQueryImageFileKeyOption (75842000) 7573e830 b9429d08 ldr w8,[x8,#0x29C] 7573e834 d63f0100 blr x8 7573e838 36225700 tbz w0,#4,kernel32!#IsFusionFullySupported+0x50 (75743318)

0:001:CHPE> u 76e12640 KERNELBASE!SetEvent: 76e12640 29be7bfd stp wfp,wlr,[sp,#-0x10]! 76e12644 910003fd mov fp,sp 76e12648 90001068 adrp x8,KERNELBASE!__hybrid_auxiliary_iat (7701e000) 76e1264c b943a508 ldr w8,[x8,#0x3A4] 76e12650 2a0003e0 mov w0,w0 76e12654 52800001 mov w1,#0 76e12658 d63f0100 blr x8 76e1265c 37f887e0 tbnz w0,#0x1F,KERNELBASE!BasepCheckImageVersion+0xe8 (76e13758)

0:001:CHPE> ub 76e0c11c KERNELBASE!#WaitForSingleObjectEx+0xdc: 76e0c0fc 110083a2 add w2,wfp,#0x20 76e0c100 b90017a2 str w2,[fp,#0x14] 76e0c104 53001e61 uxtb w1,w19 76e0c108 2a0203e2 mov w2,w2 76e0c10c 2a0003e0 mov w0,w0 76e0c110 d0001088 adrp x8,KERNELBASE!__hybrid_auxiliary_iat (7701e000) 76e0c114 b9440d08 ldr w8,[x8,#0x40C] 76e0c118 d63f0100 blr x8

0:001:CHPE> ub 5f82d9c9 ACE!ACEInitializeEx+0x65565: 5f82d9a9 000003e8 ??? ^ Memory access error in 'ub 5f82d9c9'

0:001:CHPE> ub ntdll!NtWaitForSingleObject+0xc ntdll!NtAcceptConnectPort+0xc: 779fd02c 900018c2 adrp x2,77d15000 ntdll!NtMapUserPhysicalPagesScatter: 779fd030 0a0003b8 and w24,wfp,w0 779fd034 a670ba00 ??? 779fd038 d2ff77a0 mov x0,#-0x443000000000000 779fd03c 90000cc2 adrp x2,77b95000 ntdll!NtWaitForSingleObject: 779fd040 0d0004b8 st1 {v24.b}[1],[x5] 779fd044 a670ba00 ??? 779fd048 d2ff77a0 mov x0,#-0x443000000000000

0:001:CHPE> .effmach x86 Effective machine: x86 compatible (x86)

The same is observable for the x64 process thread raw stack region pointers:

0:000> ub 00007ff7`83432ac9 pointers_c!invoke_main+0x16: 00007ff7`83432aa6 4889442430 mov qword ptr [rsp+30h],rax 00007ff7`83432aab e82ae8ffff call pointers_c!ILT+725(__p___argc) (00007ff7`834312da) 00007ff7`83432ab0 8b00 mov eax,dword ptr [rax] 00007ff7`83432ab2 89442420 mov dword ptr [rsp+20h],eax 00007ff7`83432ab6 4c8b442428 mov r8,qword ptr [rsp+28h] 00007ff7`83432abb 488b542430 mov rdx,qword ptr [rsp+30h] 00007ff7`83432ac0 8b4c2420 mov ecx,dword ptr [rsp+20h] 00007ff7`83432ac4 e8b7e7ffff call pointers_c!ILT+635(main) (00007ff7`83431280)

0:000> ub 00007ff8`046917ac ^ Unable to find valid previous instruction for 'ub 00007ff8`046917ac'

0:000> .effmach ARM64EC
Effective machine: ARM64EC (CHPEv2 on X64) (ARM64EC)

0:000:ARM64EC> ub 00007ff7`83432ac9 pointers_c!invoke_main+0x19: 00007ff7`83432aa9 2ae83024 ??? ^ Memory access error in 'ub 00007ff7`83432ac9'

0:000:ARM64EC> ub 00007ff8`046917ac kernel32!$iexit_thunk$cdecl$d$d+0x2c: 00007ff8`0469178c 00000000 ??? kernel32!$iexit_thunk$cdecl$i8$i8: 00007ff8`04691790 d503237f pacibsp 00007ff8`04691794 a9bf7bfd stp fp,lr,[sp,#-0x10]! 00007ff8`04691798 910003fd mov fp,sp 00007ff8`0469179c d10083ff sub sp,sp,#0x20 00007ff8`046917a0 b0000048 adrp x8,kernel32!_os_arm64x_dispatch_call_no_redirect (00007ff8`0469a000) 00007ff8`046917a4 f9400110 ldr xip0,[x8] 00007ff8`046917a8 d63f0200 blr xip0

0:000:ARM64EC> .effmach AMD64 Effective machine: x64 (AMD64)

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

Crash Dump Analysis Patterns (Part 304)

Dmitry Vostokov — Sun, 07 Dec 2025 22:36:04 +0000

The Latent Structure pattern addresses situations where a memory region appears raw and untyped yet shows early, incomplete signs of structural organization. Signals, such as small or pointer-like values, alignment regularities, recurring byte sequences, partial strings, or fragments that resemble fields, suggest that a real structure might exist, but cannot yet be interpreted safely or confidently. Latent Structure represents the pre-suspect stage in structural diagnostics: the point where the analyst notices potential form but must resist premature interpretation. Acting too early risks misclassifying problems and misidentifying root causes. Several forces complicate this stage: partial overwrites, coincidental alignments, ABI or version mismatches, and cognitive biases that encourage overinterpretation. This analysis pattern, therefore, emphasizes careful, hypothesis-driven exploration using techniques such as tentative structure casting, pointer-chain heuristics, checks for internal semantic coherence, software internals, and domain knowledge, all without assuming the structure’s validity. When enough evidence accumulates, a Latent Structure transitions into a Suspect Structure (subject of the next analysis pattern), where it becomes testable.

For example, we may see these fragment in Execution Residue:

00000029`e7efeb00 00001f80`0010004b 00000029`e7efeb08 0053002b`002b0033 00000029`e7efeb10 00000242`002b002b

Finally, we write the formal pattern structure card.

Intent

Detect hidden or unclear structural organization in raw memory regions that exhibit early indicators of structure-like form but whose types are not yet known.

Context

Appears in:
Execution Residue, Pointer Cone, Memory Region, and Region Strata.

Problem

A memory dump shows a region of raw bytes without explicit type information that contains hints suggesting that a structure may be present. Prematurely interpreting such memory can lead to false positives, misclassification, incorrect casting, and a chain of misleading hypotheses.

Forces

Data:

Memory may contain partial structures
Overwrites blur structure boundaries
Random-looking regions may hide structured subregions

Semantics:

Pointer-like values may be real or coincidental
Partial strings
Field alignments may appear regular due to chance

Modules:

Coincidental symbols
ABI or version mismatches

Cognitive biases:

Insufficient domain knowledge
Premature suspicion

Symptoms

Structural hints in bytes
Pointer-like values
Strings and identity hints
Alignment and regularity
Recurring patterns across multiple memory locations
Partial structure validity
Incomplete or corrupt-like structure

Resolution Strategies

Structure casting
Heuristic field and pointer chain analysis
Verification of internal semantic coherence

Resulting Context

Structure becomes Suspect and testable for validity.

Related Patterns

Hidden Artifact Patterns, Corrupt Structure, Module Hint, Falsity and Coincidence Patterns, Shared Buffer Overwrite, Value References, Small Value, Design Value, Shared Structure, and Regular Data.

Formal Card

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

Crash Dump Analysis Patterns (Part 303)

Dmitry Vostokov — Sun, 30 Nov 2025 14:08:48 +0000

When looking at Execution Residue in Windows ARM64 memory dumps, we may notice Encoded Pointers in the form of authenticated pointers (PAC, Pointer Authentication Code, see the Linux guide and Windows info). For example:

0:000> dps 00000053f62fc000 00000053f6300000 ... 00000053`f62ffe28 e817fff7`6a0bc054 functions_c!__scrt_common_main+0x14 ...

The return address isn’t possible to use directly (Invalid Pointer):

0:000> ub e817fff7`6a0bc054 e817fff7`6a0bc034 ?? ??? ^ Memory access error in ‘ub e817fff7`6a0bc054′

However, the symbolic reference is ok:

0:000> ub functions_c!__scrt_common_main+0x14 functions_c!pre_cpp_initialization+0x7c: 00007ff7`6a0bc034 00000000 ??? 00007ff7`6a0bc038 00000000 ??? 00007ff7`6a0bc03c 00000000 ??? functions_c!__scrt_common_main: 00007ff7`6a0bc040 d503237f pacibsp 00007ff7`6a0bc044 a9bf7bfd stp fp,lr,[sp,#-0x10]! 00007ff7`6a0bc048 910003fd mov fp,sp 00007ff7`6a0bc04c 97ffd81f bl functions_c!ILT+4284(__security_init_cookie) (00007ff7`6a0b20c8) 00007ff7`6a0bc050 94000016 bl functions_c!__scrt_common_main_seh (00007ff7`6a0bc0a8)

Because of that, Rough Stack that uses the dpS WinDbg command instead, omits such valid symbolic references.

If you find such pointers, you can replace the higher 4-byte part with the higher part of the module start address, for example:

0:000> lm start end module name 00007ff7`6a0a0000 00007ff7`6a0d0000 functions_c …

0:000> ub 00007ff7`6a0bc054 functions_c!pre_cpp_initialization+0×7c: 00007ff7`6a0bc034 00000000 ??? 00007ff7`6a0bc038 00000000 ??? 00007ff7`6a0bc03c 00000000 ??? functions_c!__scrt_common_main: 00007ff7`6a0bc040 d503237f pacibsp 00007ff7`6a0bc044 a9bf7bfd stp fp,lr,[sp,#-0×10]! 00007ff7`6a0bc048 910003fd mov fp,sp 00007ff7`6a0bc04c 97ffd81f bl functions_c!ILT+4284(__security_init_cookie) (00007ff7`6a0b20c8) 00007ff7`6a0bc050 94000016 bl functions_c!__scrt_common_main_seh (00007ff7`6a0bc0a8)

Of course, this may not work for pointers, encoded by the Windows EncodePointer API.

Finally, we write the formal pattern structure card for Encoded Pointer.

Intent

To recognize situations where a pointer stored in memory is not directly usable: its value must be interpreted or transformed before it can be resolved to a valid code or data address.

Context

Appears in:
Stack Trace, Execution Residue, Context Pointer, Historical Information.

Common environments:

Tagged pointers
ARM64 pointer authentication (PAC)
Top-Byte-Ignore tagging (AArch64)
ASLR and relocations that have not yet been applied in the captured memory
Managed space compressed and metadata-embedded GC pointers
Objective-C and Swift tagged ISA pointers
Sanitizers or checking runtimes that add metadata bits

Problem

A pointer in the dump visually appears to be an address, but fails to resolve using normal symbolic or spatial checks; dereferencing its raw value yields an incorrect memory address or a memory error.

Forces

Performance/security constraints favor encoded pointer formats
Debugger views often show raw stack/heap
Encoding schemes vary by platform and compiler
Hardware PAC may prevent guessing the correct pointer form without a proper decode context

Symptoms

Pointer value not inside any loaded module or valid virtual address range
Symbol resolution differs
Adjacent stack slots look pointer-like, but this one does not
Backwards disassembly shows an incorrect frame

Resolution Strategies

Decode PAC
Canonicalize upper bits
Strip tags
Expand bits
Apply relocation deltas
Mask metadata

Resulting Context

After correct interpretation, the pointer becomes:

Resolvable to a target symbol
Walkable for call-stack reconstruction
Safe for dereferencing in analysis context
Enables further analysis

Formal card

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

Crash Dump Analysis Patterns (Part 302)

Dmitry Vostokov — Mon, 17 Nov 2025 21:16:32 +0000

The list of local variables displayed by the dv WinDbg command may contain False Local Addresses, especially if some non-standard alignment is used on ARM64 platforms. For example, we get this address that doesn’t look correct if we associate it with the source code:

* _Alignas(4096) long long ll = 1;

0:000> dv /V 0000000b`970fe260 @x27+0×1000 ll = 0n-3689348814741910324 0000000b`970fd490 @x27+0×0230 align = 8

It is not aligned on the page boundary, and the value is not the expected 1:

0:000> dq 0000000b`970fe260 L1 0000000b`970fe260 cccccccc`cccccccc

However, in the disassembly, we see the following sequence of instructions to initialize the variable:

00007ff7`d061afdc f9533f69 ldr x9,[x27,#0x2678] 00007ff7`d061afe0 d2800028 mov x8,#1 00007ff7`d061afe4 f9000128 str x8,[x9]

So, we can see that the local variable address is stored at x27+0×2678:

0:000> dp x27+0x2678 L1 0000000b`970ff8d8 0000000b`970fd000

and see the correct variable value:

0:000> dpp x27+0x2678 L1 0000000b`970ff8d8 0000000b`970fd000 00000000`00000001

This analysis pattern differs from False Effective Address analysis pattern in the correct value of the base register.

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

Crash Dump Analysis Patterns (Part 26b)

Dmitry Vostokov — Sun, 16 Nov 2025 14:29:56 +0000

On Windows 11 ARM64, it is possible to run x64 and x86 programs (ARM64EC and Compiled Hybrid Portable Executable, CHPE). When we capture memory dumps and examine the corresponding Stack Trace Collection, we see ARM64EC and CHPE frames. This is similar to our earlier Virtualized Process (WOW64) analysis pattern, although WinDbg can show us different architecture frames at the same time. Below are 2 examples of NULL Pointer (Data) analysis pattern.

* x64 process minidump

0:000> ~*kL

. 0 Id: 8030.677c # Arch Child-SP RetAddr 00 ARM64EC 000000e0`5d2fdf30 00007ff8`02901d6c 01 ARM64EC 000000e0`5d2fdf40 00007ff8`046735e0 02 ARM64EC 000000e0`5d2fe220 00007ff8`046730e0 03 ARM64EC 000000e0`5d2fe390 00007ff8`0463d3e4 04 ARM64EC 000000e0`5d2fe3f0 00007ff8`02a047e8 05 ARM64EC 000000e0`5d2fe410 00007ff8`0754f7c4 06 ARM64EC 000000e0`5d2fe500 00007ff8`07547148 07 ARM64EC 000000e0`5d2fe510 00007ff8`0749a304 08 ARM64EC 000000e0`5d2fe570 00007ff8`07547068 09 ARM64EC 000000e0`5d2fe5f0 00007ff8`07440820 0a ARM64EC 000000e0`5d2fe610 00007ff8`07546e50 0b ARM64EC 000000e0`5d2fed90 00007ff7`128d1ccc 0c AMD64 000000e0`5d2ff8e0 00007ff7`128d2ac9 0d AMD64 000000e0`5d2ffdb0 00007ff7`128d2972 0e AMD64 000000e0`5d2ffe00 00007ff7`128d282e 0f AMD64 000000e0`5d2ffe70 00007ff7`128d2b5e 10 AMD64 000000e0`5d2ffea0 00007ff8`046917ac 11 ARM64EC 000000e0`5d2ffed0 00007ff8`046115e8 12 ARM64EC 000000e0`5d2fff00 00007ff8`0748c120 13 ARM64EC 000000e0`5d2fff10 00000000`00000000 Suspend: 0 Teb: 000000e0`5d015000 Unfrozen Call Site ntdll!#NtWaitForMultipleObjects+0x14 KERNELBASE!#WaitForMultipleObjectsEx+0xfc kernel32!#WerpReportFaultInternal+0x4c0 kernel32!#WerpReportFault+0xe0 kernel32!#BasepReportFault+0x24 KERNELBASE!#UnhandledExceptionFilter+0x308 ntdll!RtlUserThreadStart$filt$0+0x64 ntdll!#__C_ExecuteExceptionFilter+0x38 ntdll!#__C_specific_handler+0xf4 ntdll!#RtlpExecuteHandlerForException+0x28 ntdll!#RtlDispatchException+0x298 ntdll!KiUserExceptionDispatcher_DetourReturn+0x10 pointers_c!main+0x41c pointers_c!invoke_main+0x39 pointers_c!__scrt_common_main_seh+0x132 pointers_c!__scrt_common_main+0xe pointers_c!mainCRTStartup+0xe kernel32!$iexit_thunk$cdecl$i8$i8+0x1c kernel32!#BaseThreadInitThunk+0x48 ntdll!#RtlUserThreadStart+0x70

1 Id: 8030.7a64 Suspend: 0 Teb: 000000e0`5d017000 Unfrozen # Arch Child-SP RetAddr Call Site 00 ARM64EC 000000e0`5d3ff820 00007ff8`07470084 ntdll!#NtWaitForWorkViaWorkerFactory+0x14 01 ARM64EC 000000e0`5d3ff830 00007ff8`046115e8 ntdll!#TppWorkerThread+0x5a4 02 ARM64EC 000000e0`5d3ffaf0 00007ff8`0748c120 kernel32!#BaseThreadInitThunk+0x48 03 ARM64EC 000000e0`5d3ffb00 00000000`00000000 ntdll!#RtlUserThreadStart+0x70

2 Id: 8030.119c Suspend: 0 Teb: 000000e0`5d019000 Unfrozen # Arch Child-SP RetAddr Call Site 00 ARM64EC 000000e0`5d4ff980 00007ff8`07470084 ntdll!#NtWaitForWorkViaWorkerFactory+0x14 01 ARM64EC 000000e0`5d4ff990 00007ff8`046115e8 ntdll!#TppWorkerThread+0x5a4 02 ARM64EC 000000e0`5d4ffc50 00007ff8`0748c120 kernel32!#BaseThreadInitThunk+0x48 03 ARM64EC 000000e0`5d4ffc60 00000000`00000000 ntdll!#RtlUserThreadStart+0x70

3 Id: 8030.70f0 Suspend: 0 Teb: 000000e0`5d01b000 Unfrozen # Arch Child-SP RetAddr Call Site 00 ARM64EC 000000e0`5d5ff810 00007ff8`07470084 ntdll!#NtWaitForWorkViaWorkerFactory+0x14 01 ARM64EC 000000e0`5d5ff820 00007ff8`046115e8 ntdll!#TppWorkerThread+0x5a4 02 ARM64EC 000000e0`5d5ffae0 00007ff8`0748c120 kernel32!#BaseThreadInitThunk+0x48 03 ARM64EC 000000e0`5d5ffaf0 00000000`00000000 ntdll!#RtlUserThreadStart+0x70

4 Id: 8030.4720 Suspend: 0 Teb: 000000e0`5d01d000 Unfrozen # Arch Child-SP RetAddr Call Site 00 ARM64EC 000000e0`5d6ff740 00007ff8`0487ec00 ntdll!#NtWaitForSingleObject+0x14 01 ARM64EC 000000e0`5d6ff750 00007ff8`0487e2b0 xtajit64!BeginSimulation+0x12eb0 02 ARM64EC 000000e0`5d6ff7a0 00007ff8`0748c0f0 xtajit64!BeginSimulation+0x12560 03 ARM64EC 000000e0`5d6ff7d0 00000000`00000000 ntdll!#RtlUserThreadStart+0x40

0:000> .frame /c 4 04 000000e0`5d2fe3f0 00007ff8`02a047e8 kernel32!#BasepReportFault+0x24 x0=0000000000000003 x1=000000e05d2fe2e0 x2=0000000000000001 x3=0000000000000000 x4=0000000000000000 x5=0000000000000000 x6=0000000000000000 x7=0000000000000000 x8=000000000000012c x9=0000000000000000 x10=0000000000000000 x11=0000000000000000 x12=0000000000000000 x13=0000000000000000 x14=0000000000000000 x15=0000000000000000 x16=0000bbd3fe198401 x17=0000bbd3fe198401 x18=0000000000000000 x19=000000e05d2fe5a0 x20=0000000000000000 x21=000000e05d2fe5a0 x22=00007ff8045a0000 x23=0000000000000000 x24=0000000000000000 x25=0000000000000000 x26=000000e05d2fe410 x27=0000000000000001 x28=0000000000000000 fp=000000e05d2fe3f0 lr=00007ff80463d3e4 sp=000000e05d2fe3f0 pc=00007ff80463d3e4 psr=60000000 -ZC- EL0 kernel32!#BasepReportFault+0x24: 00007ff8`0463d3e4 14000002 b kernel32!#BasepReportFault+0x2c (00007ff8`0463d3ec)

0:000:ARM64EC> .frame /c c 0c 000000e0`5d2ff8e0 00007ff7`128d2ac9 pointers_c!main+0x41c [C:\ACPPWD\pointers_c\pointers_c.c @ 133] rax=0000000000000004 rbx=0000000000000000 rcx=9ff2ebf5ac870000 rdx=00007ff7128dabc0 rsi=0000000000000000 rdi=000000e05d2ffc18 rip=00007ff7128d1ccc rsp=000000e05d2ff8e0 rbp=000000e05d2ff930 r8=00000000fffffffe r9=0000000000000000 r10=0000000000000001 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=3 nv up ei pl zr na pe nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00003240 pointers_c!main+0x41c: 00007ff7`128d1ccc c70000000000 mov dword ptr [rax],0 ds:00000000`00000004=????????

0:000> .cxr Resetting default scope

0:000:ARM64EC>

* x86 process full dump

0:000> ~*kL

. 0 Id: 1a68.8a54 Suspend: 0 Teb: 0295d000 Unfrozen # Arch ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 00 x86 02afe454 779dd5dc 0x2730002 01 x86 02afe458 75eb2f10 ntdll!NtWaitForMultipleObjects+0xc 02 CHPE 02afe460 75eb2f10 KERNELBASE!$push_thunk$stdcall$u$uuuuu+0x60 03 CHPE 02afe4e0 75d30840 KERNELBASE!#WaitForMultipleObjectsEx+0x194 04 CHPE 02afe680 7712bc70 KERNELBASE!#WaitForMultipleObjects+0x20 05 CHPE 02afe690 7712b690 kernel32!#WerpReportFaultInternal+0x598 06 CHPE 02afe790 770e7fe4 kernel32!#WerpReportFault+0x118 07 CHPE 02afe800 75e90da8 kernel32!#BasepReportFault+0x24 08 CHPE 02afe820 779141b4 KERNELBASE!#UnhandledExceptionFilter+0x378 09 CHPE 02afe8f0 77910ef8 ntdll!strrchr+0x1eb4 0a CHPE 02afe910 778cf388 ntdll!#__C_ExecuteExceptionFilter+0x38 0b CHPE 02afe970 77861554 ntdll!#__C_specific_handler+0xf8 0c CHPE 02afe9e0 779b7154 ntdll!RtlpExecuteHandlerForExceptionCHPE+0x14 0d x86 02afeee0 779b7154 ntdll!RtlDispatchExceptionCHPE+0x2de 0e x86 02aff2bc 779e08d2 ntdll!RtlpProcessPushThunkForException+0x7b 0f x86 02aff354 779e0e5f ntdll!RtlDispatchException+0×1ee 10 x86 02aff360 02aff36c ntdll!KiUserExceptionDispatcher+0xf 11 x86 02aff88c 00712a03 0×2aff36c 12 x86 02aff8ac 0071284a pointers_c!invoke_main+0×33 13 x86 02aff908 007126dd pointers_c!__scrt_common_main_seh+0×15a 14 x86 02aff910 00712a88 pointers_c!__scrt_common_main+0xd 15 x86 02aff918 771487a8 pointers_c!mainCRTStartup+0×8 16 CHPE 02aff920 771487a8 kernel32!$push_thunk$cdecl$u$u+0×58 17 CHPE 02aff990 778bfc8c kernel32!BaseThreadInitThunk+0×2c 18 CHPE 02aff9a0 778bfbe8 ntdll!#__RtlUserThreadStart+0×3c 19 CHPE 02aff9f0 7799988c ntdll!#_RtlUserThreadStart+0×28

1 Id: 1a68.8194 Suspend: 0 Teb: 02961000 Unfrozen # Arch ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 00 x86 086ff5a4 779dee8c 0x2730002 01 x86 086ff5a8 779ab648 ntdll!NtWaitForWorkViaWorkerFactory+0xc 02 CHPE 086ff5b0 779ab648 ntdll!#NtWaitForWorkViaWorkerFactory$push_thunk+0x68 03 CHPE 086ff630 7709e81c ntdll!#TppWorkerThread+0x238 04 CHPE 086ff810 778bfc8c kernel32!BaseThreadInitThunk+0x2c 05 CHPE 086ff820 778bfbe8 ntdll!#__RtlUserThreadStart+0x3c 06 CHPE 086ff870 7799988c ntdll!#_RtlUserThreadStart+0x28

2 Id: 1a68.499c Suspend: 0 Teb: 02965000 Unfrozen # Arch ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 00 x86 087ffcc4 779dee8c 0x2730002 01 x86 087ffcc8 779ab648 ntdll!NtWaitForWorkViaWorkerFactory+0xc 02 CHPE 087ffcd0 779ab648 ntdll!#NtWaitForWorkViaWorkerFactory$push_thunk+0x68 03 CHPE 087ffd50 7709e81c ntdll!#TppWorkerThread+0x238 04 CHPE 087fff30 778bfc8c kernel32!BaseThreadInitThunk+0x2c 05 CHPE 087fff40 778bfbe8 ntdll!#__RtlUserThreadStart+0x3c 06 CHPE 087fff90 7799988c ntdll!#_RtlUserThreadStart+0x28

3 Id: 1a68.63f4 Suspend: 0 Teb: 02969000 Unfrozen # Arch ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 00 x86 08b5f854 779dee8c 0x2730002 01 x86 08b5f858 779ab648 ntdll!NtWaitForWorkViaWorkerFactory+0xc 02 CHPE 08b5f860 779ab648 ntdll!#NtWaitForWorkViaWorkerFactory$push_thunk+0x68 03 CHPE 08b5f8e0 7709e81c ntdll!#TppWorkerThread+0x238 04 CHPE 08b5fac0 778bfc8c kernel32!BaseThreadInitThunk+0x2c 05 CHPE 08b5fad0 778bfbe8 ntdll!#__RtlUserThreadStart+0x3c 06 CHPE 08b5fb20 7799988c ntdll!#_RtlUserThreadStart+0x28

0:000> r eax=001d005b ebx=00000180 ecx=00000003 edx=779ea670 esi=00000000 edi=00000003 eip=02730002 esp=02afe458 ebp=02afe480 iopl=0 nv up ei ng nz ac po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0023 efl=00000293 02730002 c3 ret

0:000> .frame /c 7 07 02afe800 75e90da8 kernel32!#BasepReportFault+0x24 x0=0000000000000000 x1=0000000000000000 x2=0000000000000000 x3=0000000000000000 x4=0000000000000000 x5=0000000000000000 x6=0000000000000000 x7=0000000000000000 x8=0000000000000000 x9=0000000000000000 x10=0000000000000000 x11=0000000000000000 x12=0000000000000000 x13=0000000000000000 x14=0000000000000000 x15=0000000000000000 x16=0000000000000000 x17=0000000000000000 x18=0000000000000000 x19=0000000002afe990 x20=0000000002afe990 x21=0000000077090000 x22=0000000000000004 x23=0000000000000000 x24=0000000000000001 x25=0000000075f1e000 x26=0000000000000000 x27=0000000002afe830 x28=0000000002affa38 fp=0000000002afe800 lr=00000000770e7fe4 sp=0000000002afe800 pc=00000000770e7fe4 psr=00000000 ---- EL0 kernel32!#BasepReportFault+0x24: 770e7fe4 2a0003e0 mov w0,w0

0:000:CHPE> .cxr Resetting default scope

0:000> dps 02aff354 02aff354 02aff88c 02aff358 779e0e5f ntdll!KiUserExceptionDispatcher+0xf 02aff35c 02aff36c 02aff360 02aff3bc 02aff364 02aff36c 02aff368 02aff3bc 02aff36c c0000005 02aff370 00000000 02aff374 00000000 02aff378 00711c6a pointers_c!main+0×3da 02aff37c 00000002 02aff380 00000001 02aff384 00000004 02aff388 00000000 02aff38c 00000000 02aff390 00000000 02aff394 00000000 02aff398 00000000 02aff39c 00000000 02aff3a0 00000000 02aff3a4 00000000 02aff3a8 00000000 02aff3ac 00000000 02aff3b0 00000000 02aff3b4 00000000 02aff3b8 00000000 02aff3bc 0001003f 02aff3c0 00000000 02aff3c4 00000000 02aff3c8 00000000 02aff3cc 00000000 02aff3d0 ffff0ff0

0:000> .cxr 02aff3bc eax=00000004 ebx=0295a000 ecx=02aff4a0 edx=00000000 esi=02aff6a8 edi=02aff88c eip=00711c6a esp=02aff6a8 ebp=02aff88c iopl=0 nv up ei pl nz ac po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0023 efl=00010212 pointers_c!main+0×3da: 00711c6a c70000000000 mov dword ptr [eax],0 ds:0023:00000004=????????

0:000> kL *** Stack trace for last set context - .thread/.cxr resets it # Arch ChildEBP RetAddr 00 x86 02aff88c 00712a03 pointers_c!main+0x3da 01 x86 02aff8ac 0071284a pointers_c!invoke_main+0x33 02 x86 02aff908 007126dd pointers_c!__scrt_common_main_seh+0x15a 03 x86 02aff910 00712a88 pointers_c!__scrt_common_main+0xd 04 x86 02aff918 771487a8 pointers_c!mainCRTStartup+0x8 05 CHPE 02aff920 771487a8 kernel32!$push_thunk$cdecl$u$u+0x58 06 CHPE 02aff990 778bfc8c kernel32!BaseThreadInitThunk+0x2c 07 CHPE 02aff9a0 778bfbe8 ntdll!#__RtlUserThreadStart+0x3c 08 CHPE 02aff9f0 7799988c ntdll!#_RtlUserThreadStart+0x28

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

Trace Analysis Patterns (Part 255)

Dmitry Vostokov — Sat, 01 Nov 2025 21:09:11 +0000

We write software based on requirements and then see its execution. The same analogy can be applied to Declarative Traces, which are “executed.” Trace Plans serve the role of tracing and logging requirements. The following diagram illustrates trace engineering and the lifecycle of tracing and logging:

We look at a resulting trace or log and relate it to its Trace Plan to find anomalies and problems not only in software execution but also in traces and logs themselves and improve tracing source code.

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

Trace Analysis Patterns (Part 254)

Dmitry Vostokov — Sun, 26 Oct 2025 21:09:21 +0000

When we get traces and logs, we are interested in Trace Context: an issue description, how its trace was collected, overall system information, related Adjoint Spaces, Trace Summary, and previous traces and logs and their analyses. This contextual information can be organized as a checklist to ensure situational awareness, diagnostic quality, and reduce the number of information request roundtrips.

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

Crash Dump Analysis Patterns (Part 301)

Dmitry Vostokov — Tue, 21 Oct 2025 17:49:12 +0000

When we get memory dumps, we are interested in Dump Context: an issue description, how its memory dump was collected, overall system information, related Paratext, and previous memory dumps and their analyses. This contextual information can be organized as a checklist to ensure situational awareness, diagnostic quality, and reduce the number of information request roundtrips.

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