Software Diagnostics Library

Motivated by 7 Habits of Highly Effective Debuggers I would like to reflect on a distinction between diagnostics and problem solving as separate processes (although highly related). First, we reverse the precept from that article because stories such as software logs and traces are of primary importance to software diagnostics (and not only). And without diagnostics there is no effective debugging (treatment, problem solving, etc.)

The Principle Precept of Diagnostics

Stories NOT Statistics secure certainty.

Next parts will be about actual habits so please stay tuned. I would try to finish this list before the forthcoming Webinar on software diagnostics.

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

In some cases it is useful to consider Message Context: a set of surrounding messages having some relation to the chosen message:

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

Sometimes we need to pay attention to Error Distribution, for example, the distribution of the same error across a software log space or different error messages in different parts of the same software log or trace (providing effective partition):

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

If Break-in Activity is usually unrelated to a thread or an adjoint thread which has a discontinuity then Resume Activity pattern highlights messages from that thread:

The difference can be seen on the following graphical representation of two traces we analyzed where in a working trace a break-in preceded resume activity whereas in a non-working trace both patterns were absent:

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

We resume our software trace analysis pattern catalog. The next pattern is called Break-in Activity. This is a message or a set of messages that surface just before the end of discontinuity of a adjoint thread and possibly triggered it:

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

After writing about music for debugging and founding software narratology I decided to start writing about fiction. The first masterpiece is The Sound and The Fury by William Faulkner. I confess that I’m in love with Folio Society books and when I saw this color version (an original idea by Faulkner now fulfilled by modern printing technology) I immediately recognized its importance for software trace analysis:

http://www.foliosociety.com/book/SAF/sound-and-the-fury

I’m pretty sure Faulkner would have been delighted to see trace analysis patterns and how they may help in writing fiction.

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

In a week this short full color book should appear in online bookstores:

• Title: Software Narratology: An Introduction to the Applied Science of Software Stories
• Authors: Dmitry Vostokov, Memory Dump Analysis Services
• Description: This is a transcript of Memory Dump Analysis Services Webinar about Software Narratology: an exciting new discipline and a field of research founded by DumpAnalysis.org. When software executes it gives us its stories in the form of UI events, software traces and logs. Such stories can be analyzed for their structure and patterns for troubleshooting, debugging and problem resolution purposes. Topics also include software narremes and their types, anticipatory software construction and software diagnostics.
• Publisher: OpenTask (April 2012)
• Language: English
• Product Dimensions: 28.0 x 21.6
• Paperback: 26 pages
• ISBN-13: 978-1908043078

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

Memory Dump Analysis Services organizes a free Webinar on Unified Software Diagnostics (USD) and the new scalable cost-effective software support model called Pattern-Driven Software Support devised to address various shortcomings in existing tiered software support organizations. Examples cover Windows, Mac OS  and Linux.

Date: 22nd of June, 2012
Time: 17:00 (BST) 12:00 (EST) 09:00 (PST)
Duration: 60 minutes

Space is limited.
Reserve your Webinar seat now at:
https://www3.gotomeeting.com/register/172771078

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

Software trace analysis is notoriously difficult so a bit of folk music is needed to make debugging sessions less boring. The following album came to my attention in a local library and after listening to it I recommend it for software log analysis sessions:

Make It Through This World

Here’s my own track title interpretation:

1. Dream Away The Defects
2. This I’d Analyze
3. A Magnifier
4. Make It Through This Trace
5. Don’t Let It Go Unanalyzed
6. Request-Reply Pair
7. I Love It When It’s Short
8. No Higher Specs
9. Said, Said.
10. When I Think Of You, My Customers
11. Close to The Defect
12. A Debugger For You Now

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

Narrative theory distinguishes between frame types such as (Fludernik, McHale, Nelles, Wolf):

- introductory framing (missing end frame) [—————————-

- terminal framing (missing opening frame) —————————-]

- [—————————-]

- interpolated framing [—-[  ]—-[     ]——–]

At the level of the software trace or an adjoint thread as a whole the first 3 types correspond to various types of this pattern Partition: Head, Prologue, Core, Epilogue, Tail where certain parts are missing. The first 2 types can also be instances of Truncated Trace pattern. Interpolated framing can be an instance of multiple discontinuities. All 4 types also correspond to foreground component messages and in general we have multiple Trace Frames as depicted:

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

The previous definition of software narratology was restricted to software traces and logs (the top left quadrant on a software narrative square, also the part of Memoretics which studies memory snapshots). Now, with the broadening of the domain of software narratology to the whole world of software narrative stories including actor interactions with software in construction requirements use cases and post-construction incidents we give another definition:

Software narrative is a representation of software events and changes of state. Software Narratology is a discipline that studies such software narratives (software narrative science).

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

After introducing software narrative planes it is logical to expand the field of software narratology to cover the whole domain of software construction and post-construction. We therefore combine both pairs of planes to create a narratological square:

Please also register for the forthcoming free Webinar: Introduction to Software Narratology where I plan to provide a coherent overview of the recent developments in this new field.

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

Based on an idea of expression and content planes from glossematics with a basic unit of glosseme we can organize software traces with corresponding patterns and software trace narremes (basic units of software narrative such as traces and event logs) into 2 planes: software trace narrative plane (expression) with narremes and the corresponding program lines of traces (PLOTs) source code and design plane (content) with their own set of construction narremes such as collaboration of software constructs. All this corresponds to the following diagram:

The same can be said about actor interaction level of software construction (what ought to be) and post-construction (what is) phases having their own construction and post-construction narratives, patterns and narremes such as in requirements (use cases) and in problem and software incident descriptions:

In the forthcoming articles I provide more examples and explanations including specific software narremes useful from the practical post-construction software problem solving perspective. Please also register for the forthcoming free Webinar: Introduction to Software Narratology where I plan to provide a coherent overview of this new field.

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

I was recently asked by a group of trainees to outline a simple approach to proceed after opening a memory dump. So I came up with these 7 steps:

1. !analyze -v [-hang]
2. Exception (Bugcheck): stack trace analysis with d* and lmv
3. !locks
4. !runaway f (!running)
5. Dump all (processes and) thread stack traces [with 32-bit] ~*kv (!process 0 ff)
6. Search for signs/patterns of abnormal behavior (exceptions, wait chains, message boxes [, from your custom checklist])
7. Narrow analysis down to a specific thread and dump raw stack data if needed [repeat*]

(commands/options in brackets denote kernel/complete dump variation)
[notes in square brackets denote additional options, such as x64 specifics, your product details, etc.]

What are your steps? I would be interested to hear about alternative analysis steps, techniques, etc.

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

Memory Dump Analysis Services (DumpAnalysis.com) organizes a free Webinar about software narratology: an application of ideas from narratology to software narrative stories.

Learn about this exciting new discipline and a field of research. When software executes it gives us its stories in the form of UI events, software traces and logs. Such stories can be analyzed for their structure and patterns for troubleshooting, debugging and problem resolution purposes.

Prerequisites: basic software troubleshooting and ability to read software generated logs.

Audience: anyone can benefit from this new perspective: from software users to software engineers and managers.

Space is limited.
Reserve your Webinar seat now at:
https://www3.gotomeeting.com/register/603136294

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

In narratology anti-narrative denotes a narrative having sequences of events impossible in reality. In software traces such sequences usually depict abnormal software behaviour. Here are some parallels with corresponding trace analysis patterns:

Fiction                     | Software Trace
================================================
Repeated unrepeatable       | Periodic Error (?)
Denarration (erasure)       | No Activity / Incomplete History
Chronological contradiction | Impossible Trace

Question mark means that possibly another pattern is needed there.

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

Forthcoming Accelerated Software Trace Analysis training requires extensive real life like software logs with multiple software behaviour patterns. The similar accelerated memory dump analysis trainings (unmanaged / native Windows and .NET) also required good memory dumps but this problem was solved by modeling patterns of abnormal software behaviour in an appropriate implementation language such as C++ and C#. Modeling software traces with hundreds of software components, processes and threads would require enormous programming efforts. Therefore, the natural approach is to describe a desired software trace in some declarative language (or minimally imperative) and get a million line software log that models a specific combination of trace analysis patterns. So, welcome to such a language called Narralog: Software Narrative Log  or Narrative Logic. Please note that this language is different from Riemann programming language which is a language to describe software problems and generate software problem solving tools. Language details and whether a kind of a Metadefect Template Library will be used to implement Narralog or simple macroprogramming is suffice will be decided and announced when we further develop our training.

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

John Randall’s blog about narratology and narremes suggested me to elaborate on a basic software trace (log) unit. One candidate is a trace message invariant, a skeleton trace message similar to a format string. There is also a corresponding software trace analysis pattern called Message Invariant. Although, this might be too an elementary unit akin to a sentence level and another candidate is a macromessage, a combination of several messages serving some semantic function. There is a corresponding general pattern Macrofunction and an example concrete analysis pattern called Exception Stack Trace. The actual software narreme might be situated between these two extremes: invariants and macrofunctions.

If you are new to a software narratology field please look at these posts placed in chronological order (except a pattern catalog):

• Software Narratology: A Definition
• Basic Software PLOTs (Part 0)
• Two Readings of a Software Trace
• The Extended Software Trace
• Presenting a Software Story
• Close and Deconstructive Readings of a Software Trace
• Software Trace Analysis Pattern Catalog

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

Memory Dump Analysis Services starts providing debugging training and assistance in addition to (based on) memory dump and software trace analysis. It has recently registered www.debugging.pro domain and is working on extending its courses to cover live debugging and additional OS platforms this year.

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

I have discovered that Romantic era music is good for debugging, memory dump and software trace analysis sessions. Previously I included Beethoven and now suggest to listen to Schumann. For a starter you can try this album: Schumann: Symphonies Nos. 1-4

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