Archive for the ‘Software Trace Visualization’ Category

Debugging in 2021: Trends for the Next Decade (Part 1)

Friday, December 17th, 2010

As the new decade is approaching (2011-2020) we would like to make a few previews and predictions:

- Increased complexity of software will bring more methods from biological, social sciences and humanities in addition to existing methods of automated debugging and computer science techniques

- Focus on first fault software problem solving (when aspect)

- Focus on pattern-driven software problem solving (how aspect)

- Fusion of debugging and malware analysis into a unified structural and behavioral pattern framework

- Visual debugging, memory and software trace visualization techniques

- Software maintenance certification

- Focus on domain-driven troubleshooting and debugging tools as a service (debugware TaaS)

- Focus on security issues related to memory dumps and software traces

- New scripting languages and programming language extensions for debugging

- The maturation of the science of memory snapshots and software traces (memoretics)

Imagining is not not limited to the above and more to come and explain in the forthcoming parts.

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

Forthcoming Memory Dump Analysis Anthology, Volume 5

Friday, November 12th, 2010

Five volumes of cross-disciplinary Anthology (dubbed by the author “The Summa Memorianica”) lay the foundation of the scientific discipline of Memoretics (study of computer memory snapshots and their evolution in time) that is also called Memory Dump and Software Trace Analysis.ca

The 5th volume contains revised, edited, cross-referenced, and thematically organized selected DumpAnalysis.org blog posts about crash dump, software trace analysis and debugging written in February 2010 - October 2010 for software engineers developing and maintaining products on Windows platforms, quality assurance engineers testing software on Windows platforms, technical support and escalation engineers dealing with complex software issues, and security researchers, malware analysts and reverse engineers. The fifth volume features:

- 25 new crash dump analysis patterns
- 11 new pattern interaction case studies (including software tracing)
- 16 new trace analysis patterns
- 7 structural memory patterns
- 4 modeling case studies for memory dump analysis patterns
- Discussion of 3 common analysis mistakes
- Malware analysis case study
- Computer independent architecture of crash analysis report service
- Expanded coverage of software narratology
- Metaphysical and theological implications of memory dump worldview
- More pictures of memory space and physicalist art
- Classification of memory visualization tools
- Memory visualization case studies
- Close reading of the stories of Sherlock Holmes: Dr. Watson’s observational patterns
- Fully cross-referenced with Volume 1, Volume 2, Volume 3, and Volume 4

Product information:

  • Title: Memory Dump Analysis Anthology, Volume 5
  • Author: Dmitry Vostokov
  • Language: English
  • Product Dimensions: 22.86 x 15.24
  • Paperback: 400 pages
  • Publisher: Opentask (10 December 2010)
  • ISBN-13: 978-1-906717-96-4
  • Hardcover: 400 pages
  • Publisher: Opentask (10 December 2010)
  • ISBN-13: 978-1-906717-97-1

Back cover features memory space art image Hot Computation: Memory on Fire.

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

Debugged! MZ/PE March print issue is out

Sunday, September 19th, 2010

Finally, after the delay, the issue is available in print on Amazon and through other sellers:

Debugged! MZ/PE: Multithreading

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

Presenting a Software Story

Sunday, July 4th, 2010

It’s time to introduce a conceptual software narratological framework for viewing software traces (using rich ETW / CDF tracing as our main focus). Here we consider a software story (fabula) as a full trace when every component was selected for tracing and emits debug messages during code execution paths. However, during viewing we can filter on and off certain modules, threads, processes, messages, etc. (adjoint threading) and see a different sub-story or plot (sujet). Every software plot (please do not confuse with PLOT acronym) can be presented differently (using appropriate discourse). Some presentational examples include temporal rearrangement, collapse of repetitive regions, source code hypertext (lexia) and allegorical devices such as message tool-tip comments. Here is a diagram that depicts story (fable, fabula) - plot (sujet) - presentation (discourse):

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

Museum of Debugging and Memory Dumps

Wednesday, June 23rd, 2010

Looks like reading Darwin biography influenced me in the direction of founding a museum. So I did and here’s its draft logo:

This multi-dimensional museum will show exhibitions dedicated to the history of debugging, memory dump artifacts and art. Stay tuned. The first exhibition opens very soon.

If you would like to donate an exhibit (for example, an old memory dump or a picture related to debugging) please use this page: http://www.dumpanalysis.org/contact. Any donations are greatly appreciated!

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

Trace Analysis Patterns (Part 25)

Tuesday, June 8th, 2010

Here we introduce a software narratological partitioning of a trace into Head, Prologue, Core, Epilogue and Tail segments. This is useful for comparative software trace analysis. Suppose, a trace started just before the reproduction steps or a start marker was injected (by CDFMarker, for example) and finished just after the last repro steps or after an end marker was injected. Then its core trace messages are surrounded by prologue and epilogue statements. What is before and after are not necessary for analysis and usually distract an analyst. They are shown as grey areas on the following picture where the left trace is for working (non-working) scenario and the right trace is for non-working (working) scenario:

The size of a core segment need not be the same because environments and executed code paths might be different. However, often some traces are truncated (another pattern). Also sometimes it is difficult to establish whether the first trace is normal and the second has a tail or the first one is truncated and the second one is normal with an optional tail. Here artificial markers are important.

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

Forthcoming Memory Dump Analysis Anthology: Color Supplement for Volumes 1-3

Friday, April 30th, 2010

Memory Dump Analysis Anthology lacks full color inserts. This is rather a current limitation of POD technology that OpenTask publisher uses at the present time. The solution previously announced a year ago is to print a separate full color title with selected articles and illustrations. Finally, it is about to be published next month. The book front and back covers are collages from covers of individual memory dump analysis volumes:

TOC will be available soon. Here is the book data:

  • Title: Memory Dump Analysis Anthology: Color Supplement for Volumes 1-3
  • Author: Dmitry Vostokov
  • Publisher: OpenTask (May 2010)
  • Language: English
  • Product Dimensions: 21.6 x 14.0
  • Paperback: 110 pages
  • ISBN-13: 978-1906717698

OpenTask also plans a separate color supplement for volumes 4 and 5 once they are published. 

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

Modern Memory Dump and Software Trace Analysis: Volumes 1-3

Sunday, April 18th, 2010

OpenTask to offer first 3 volumes of Memory Dump Analysis Anthology in one set:

The set is available exclusively from OpenTask e-Commerce web site starting from June. Individual volumes are also available from Amazon, Barnes & Noble and other bookstores worldwide.

Product information:

  • Title: Modern Memory Dump and Software Trace Analysis: Volumes 1-3
  • Author: Dmitry Vostokov
  • Language: English
  • Product Dimensions: 22.86 x 15.24
  • Paperback: 1600 pages
  • Publisher: Opentask (31 May 2010)
  • ISBN-13: 978-1-906717-99-5

Information about individual volumes:

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

Component Trace

Saturday, April 17th, 2010

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

Memory Dump and Software Trace Analysis Training and Seminars

Friday, April 9th, 2010

Plan to start providing training and seminars in my free time. If you are interested please answer these questions (you can either respond here in comments or use this form for private communication http://www.dumpanalysis.org/contact):

  • Are you interested in on-site training, prefer traveling or attending webinars?
  • Are you interested in software trace analysis as well?
  • What specific topics are you interested in?
  • What training level (beginner, intermediate, advanced) are you interested in? (please provide an example, if possible)

Additional topics of expertise that can be integrated into training include Source Code Reading and Analysis, Debugging, Windows Architecture, Device Drivers, Troubleshooting Tools Design and Implementation, Multithreading, Deep Down C and C++, x86 and x64 Assembly Language Reading.

Looking forward to your responses. Any suggestions are welcome.

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

Trace Analysis Patterns (Part 21)

Thursday, April 8th, 2010

“Capturing delicate moments, one gives birth to a poetry of traces …”

Ange Leccia, Motionless Journeys, by Fabien Danesi

More patterns from software narratology. Now we illustrate Defamiliarizing Effect where we see sudden unfamiliar trace statements across familiar landscape of characteristic blocks and activity regions:

/familar traces/

 

/new trace from a problem system/

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

Trace Analysis Patterns (Part 20)

Thursday, April 8th, 2010

Metaphorical bijection from literary narratology to software narratology provides a pattern of Background and Foreground Components. This can be easily illustrated on pseudo-trace color diagrams. Suppose we troubleshoot a graphical issue using an ETW trace containing the output from all components of the problem system. Graphic components and their messages are foreground for a trace viewer (a person) against numerous background components (for example, database, file and registry access, shown in shades of green):

Trace viewers (for example, CDFAnalyzer) can filter out background component messages and present only foreground components (that I propose to call component foregrounding):

Of course, this process is iterative and parts of what once was foreground become background and candidates for further filtering:

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

Trace Analysis Patterns (Part 18)

Monday, March 8th, 2010

Sometimes we have a sequence of Activity Regions with increasing values of Statement Current, like depicted here:

The boundaries of regions may be blurry and arbitrarily drawn. Nevertheless, the current is visibly increasing or decreasing, hence the name of this pattern: Trace Acceleration, by analogy with physical acceleration, second-order derivative. We can also metaphorically use here the notion of a partial derivative for trace statement current and acceleration for Threads of Activity and Adjoint Threads of Activity but whether it is useful remains to be seen.

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

Forthcoming Memory Dump Analysis Anthology, Volume 4

Thursday, February 11th, 2010

This is a revised, edited, cross-referenced and thematically organized volume of selected DumpAnalysis.org blog posts about crash dump analysis and debugging written in July 2009 - January 2010 for software engineers developing and maintaining products on Windows platforms, quality assurance engineers testing software on Windows platforms and technical support and escalation engineers dealing with complex software issues. The fourth volume features:

- 13 new crash dump analysis patterns
- 13 new pattern interaction case studies
- 10 new trace analysis patterns
- 6 new Debugware patterns and case study
- Workaround patterns
- Updated checklist
- Fully cross-referenced with Volume 1, Volume 2 and Volume 3
- New appendixes

Product information:

  • Title: Memory Dump Analysis Anthology, Volume 4
  • Author: Dmitry Vostokov
  • Language: English
  • Product Dimensions: 22.86 x 15.24
  • Paperback: 410 pages
  • Publisher: Opentask (30 March 2010)
  • ISBN-13: 978-1-906717-86-5
  • Hardcover: 410 pages
  • Publisher: Opentask (30 April 2010)
  • ISBN-13: 978-1-906717-87-2

Back cover features memory space art image: Internal Process Combustion.

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

Extending Multithreading to Multibraiding (Adjoint Threading)

Sunday, January 17th, 2010

Having considered computational threads as braided strings and after discerning several software trace analysis patterns (just the beginning) we can see formatted and tabulated software trace output in a new light and employ the “fabric of traces” and braid metaphors for an Adjoint Thread concept. This new concept was motivated by reading about Extended Phenotype (*) and extensive analysis of Citrix ETW-based CDF traces using CDFAnalyzer. The term Adjoint was borrowed from mathematics because the concept we discuss below resembles this metaphorical formula: (Thread A, B) = [A, Thread B]. Let me first illustrate adjoint threading using simplified trace tables. Consider this generalized software trace example (date and time column is omitted for visual clarity):

#

Source Dir

PID

TID

File Name

Function

Message

1

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

2

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

3

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

4

\src\lib

2792

5680

file2.cpp

barA

Message text…

5

\src\subsystemA

2792

5680

file1.cpp

fooA

Message text…

6

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

7

\src\lib

2792

5680

file2.cpp

fooA

Message text…

8

\src\lib

2792

5680

file2.cpp

fooA

Message text…

9

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

10

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

11

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

12

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

13

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

14

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

15

\src\subsystemB

2792

2992

file4.cpp

fooB

Message text…

16

\src\subsystemB

2792

3008

file4.cpp

fooB

Message text…

We see several threads in a process PID 2792. In CDFAnalyzer we can filter trace messages that belong to any column and if we filter by TID we get a view of any Thread of Activity. However, each thread can “run” through any source directory, file name or function. If a function belongs to a library multiple threads would access it. This source location (can be considered as a subsystem), file or function view of activity is called an Adjoint Thread. For example, if we filter only subsystemA column in the trace above we get this table:

#

Source Dir

PID

TID

File Name

Function

Message

1

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

2

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

3

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

5

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

6

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

7005

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10198

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10364

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10417

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10420

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

10422

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

10587

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10767

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11126

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11131

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11398

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

11501

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11507

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11509

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

11513

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11524

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

We can graphically view subsystemA as a braid string that “permeates the fabric of threads”:

We can get many different braids by changing filters, hence multibraiding. Here is another example of a driver source file view initially permeating 2 process contexts and 4 threads:

#

Source Dir

PID

TID

File Name

Function

Message

41

\src\sys\driver

3636

3848

entry.c

DriverEntry

IOCTL …

80

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

99

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

102

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

179

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

180

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

311

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

447

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

448

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

457

\src\sys\driver

2792

5108

entry.c

DriverEntry

IOCTL …

608

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

614

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

655

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

675

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

678

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

680

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

681

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

1145

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

1153

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

1154

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

(*) A bit of digression. Looks like biology keeps giving insights into software, there is even a software phenotype metaphor albeit a bit restricted to code, I just thought that we need also an Extended Software Phenotype.

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

Multiplatform Debugging, Defect Annotation and Visualization

Sunday, December 27th, 2009

Main topics of Debugged! MZ/PE magazine issues for June and September 2010:

Debugged! MZ/PE: Multiplatform Software Defects, June, 2010 (Paperback, ISBN: 978-1906717902)

Debugged! MZ/PE: Software Defect Visualization and Annotation, September, 2010 (Paperback, ISBN: 978-1906717919)

Here are draft front covers designed today:

- Dmitry Vostokov @ DumpAnalysis.org -

Memory Dump Analysis Anthology, Volume 3

Sunday, December 20th, 2009

“Memory dumps are facts.”

I’m very excited to announce that Volume 3 is available in paperback, hardcover and digital editions:

Memory Dump Analysis Anthology, Volume 3

Table of Contents

In two weeks paperback edition should also appear on Amazon and other bookstores. Amazon hardcover edition is planned to be available in January 2010.

The amount of information was so voluminous that I had to split the originally planned volume into two. Volume 4 should appear by the middle of February together with Color Supplement for Volumes 1-4. 

- Dmitry Vostokov @ DumpAnalysis.org -

Debugged! MZ/PE September issue is out

Wednesday, December 16th, 2009

Finally, after the long delay, the issue is available in print on Amazon and through other sellers:

Debugged! MZ/PE: Software Tracing

Buy from Amazon

- Dmitry Vostokov @ DumpAnalysis.org -

Trace Analysis Patterns (Part 12)

Tuesday, November 17th, 2009

When looking at lengthy traces with thousands and millions of messages (trace statements) we can see regions of activity where statement current (Jm, msg/s) is much higher than in surrounding temporal regions. Hence the name of this pattern, Activity Region. Here is an illustration for a typical ETW/CDF trace where a middle region of activity (Jm2) signifies a system performing some response function like a user session initialization and application launch:

- Dmitry Vostokov @ TraceAnalysis.org -

Trace Analysis Patterns (Part 11)

Saturday, November 7th, 2009

Birds eye view of software traces makes it easier to see their coarse blocked structure:

where further finer structure is discernible and even nested blocks:

Some blocks of output can be seen when scrolling trace viewer output but if a viewer support zooming it is possible to get an overview and jump directly into a Characteristic Message Block, for example, debug messages of repeated attempts to query a database. If a viewer supports message coloring it also helps. Sometimes this technique is useful to ignore bulk messages and start the analysis around block boundaries.

- Dmitry Vostokov @ TraceAnalysis.org -