Trace Analysis Patterns (Part 2)

A typical trace is a detailed narrative. It is accompanied by a problem description that lists essential facts. Therefore the first task of any trace analysis is to check the presence of Basic Facts in the trace. If they are not visible or do not correspond then the trace was possibly not recorded during the problem or was taken from a different computer or under different conditions. Here is an example. A user “test01″ cannot connect to an application. We look at the trace and find this statement:

No   PID  TID  Date      Time         Statement
[...]
3903 3648 5436 4/29/2009 16:17:36.150 User Name: test01
[...]

At least we can be sure that this trace was taken for the user test01 especially when we expect this or similar trace statements. If we could not see this trace statement we can suppose that the trace was taken at the wrong time, for example, after the problem happened already.

- Dmitry Vostokov @ TraceAnalysis.org -

3 Responses to “Trace Analysis Patterns (Part 2)”

  1. Crash Dump Analysis » Blog Archive » Trace Analysis Patterns (Part 4) Says:

    […] we see a functional activity in a trace and / or see basic facts. Then we might want find a correlation between that activity or facts in another part of the trace. […]

  2. Crash Dump Analysis » Blog Archive » Trace Analysis Patterns (Part 14) Says:

    […] trace to see how corrdinates of all windows are changed over time. We easily find some Basic Facts in both traces such as window class name or time but it looks like window handle is different. In […]

  3. Crash Dump Analysis » Blog Archive » Basic facts, periodic error and defamiliarizing effect: software trace pattern cooperation Says:

    […] help and a software trace was recorded for the offline analysis. First, we checked for Basic Facts and found the correspondence that confirmed the registry key […]

Leave a Reply