G
When doing Inter-Correlational analysis between different traces and logs, we can move simultaneously along time direction or backward (Back Tracing). In some cases, we may start our analysis with the identification of Significant Events in both logs and then move in opposite directions finding another pair of messages that can be useful for diagnostic identification. We call this analysis pattern Galois Trace by analogy with Galois connection64 in mathematics. In our case moving from trace A to trace B and back corresponds to F and G functions with a and b as individual trace messages or their Message Contexts (as per monotone65 definition). The analysis pattern is illustrated in the following diagram:
Adjoint Thread invariants like PID can be reused, giving rise to curious CDF (ETW) traces where two separate execution entities are glued together in one trace. For example, in one trace, we see AppA and AppB sharing the same PID:
# Module PID TID Time Message
[...]
242583 ProcMon 5492 9476 11:04:33 LoadImageEvent for ImageName: …AppA.exe PID: 5492
256222 ProcMon 5492 9476 11:04:50 ProcessDestroyEvent for PPID: 12168 PID: 5492
274887 ProcMon 5492 1288 11:05:18 LoadImageEvent for ImageName: …AppB.exe PID: 5492
[...]
Other similar examples may include different instances of components sharing the same name, source code or even, in general, periodic tracing sessions appended to the end of the same trace file. Although we think that the latter should be a separate pattern. We named this pattern Glued Activity by an analogy of different thread strings glued together (in general, manifolds66 glued along their boundaries). Another name might be along the line of Adjoint Thread ID reuse (ATID reuse).
The following diagram illustrates common scenarios for this analysis pattern:
This pattern has a funny name Gossip. We were thinking originally to call it Duplicated Message but gave it the new name allowing for the possibility of the semantics of the same message to be distorted in subsequent trace messages from different Adjoint Threads. Here is a typical ETW / CDF trace example (distortion free) of the same message content seen in different modules (we omitted some columns like Date and Time):
# Module PID TID Message
[...]
26875 ModuleA 2172 5284 LoadImageEvent: ImageName(DeviceHarddiskVolume2WindowsSystem32 otepad.exe) ProcessId(0x000000000000087C)
26876 ModuleB 2172 5284 LoadImageEvent: ImageName(DeviceHarddiskVolume2WindowsSystem32 otepad.exe), ProcessId(2172)
26877 ModuleC 2172 5284 ImageLoad: fileName=notepad.exe, pid: 000000000000087C
[...]
In such cases, when constructing Event Sequence Order we recommend choosing messages from the one source instead of mixing events from different sources, for example:
# Module PID TID Message
[...]
26875 ModuleA 2172 5284 LoadImageEvent: ImageName(DeviceHarddiskVolume2WindowsSystem32 otepad.exe) ProcessId(0×000000000000087C)
[...]
33132 ModuleA 4180 2130 LoadImageEvent: ImageName(DeviceHarddiskVolume2WindowsSystem32calc.exe) ProcessId(0×0000000000001054)
[...]
Sometimes, when comparing normal, expected (working) and abnormal (non-working) traces, we can get a clue for further troubleshooting and debugging by looking at module load events. For example, when we see an unexpected module loaded in our non-working trace, its function (and sometimes even module name) can signify some difference to pay attention to:
# PID TID Time Message
[...]
4492 908 912 11:06:41.953 LoadImageEvent:ImageName(WINDOWSsystem323rdPartySso.dll)
[...]
We call this pattern Guest Component, and it is different from Missing Component. Although in the latter pattern, a missing component in one trace may appear in another, the component name is known apriori and expected. In the former pattern, the component is unexpected. For example, in the trace above, its partial name fragment “Sso” may trigger a suggestion to relate differences in authentication where, in a non-working case, SSO (single sign-on) was configured.
The following diagram illustrates this analysis pattern:
