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 -
June 16th, 2009 at 11:23 pm
[…] 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. […]
January 12th, 2010 at 6:03 pm
[…] 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 […]
November 15th, 2010 at 10:42 pm
[…] 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 […]