Pattern! What Pattern?

There is confusion about patterns of diagnostics such as related to crash dump analysis and software trace and log analysis. We are often asked about pattern percentage detection rate or whether it is possible to automate pattern diagnostics. Before asking and answering such questions, it is important to understand what kinds of patterns are meant. Patterns of diagnostics can be subdivided into concrete and general problem patterns, and, also, into concrete and general analysis patterns.

Problem patterns are simply diagnostic patterns, and they can be defined as (fusing Diagnostic Pattern1 and Diagnostic Problem2 definitions):

A common recurrent identifiable set of indicators (signs) together with a set of recommendations and possible solutions to apply in a specific context.

Concrete Problem Patterns are particular sets of indicators, for example, an exception stack trace showing an invalid memory access in the particular function from the particular component/module code loaded and executed on Windows platform.

But such indicators can be generalized from different products and OS platforms giving rise to General Problem Patterns forming a pattern language. Our previous example can be generalized as Exception Stack Trace showing Invalid Pointer and Exception Module. Concrete Problem Patterns are the implementation of the corresponding General Problem Patterns.

Now, it becomes clear why Memory Analysis Pattern Catalog doesn’t have any concrete BSOD bugcheck numbers. Most of such numbers are concrete implementations of Self-Diagnosis pattern.

Then we have Concrete Analysis Patterns as particular techniques to uncover Concrete Problem Patterns. For example, thread raw stack analysis for historical information to reconstruct a stack trace. Again, such techniques vary between OS platform and even between debuggers.

Generalizing again, we have General Analysis Patterns, for example, analyzing Historical Information in Execution Residue to construct Glued Stack Trace.

General Problem Pattern descriptions may already reference General Analysis Patterns, and in some cases both may coincide. For example, Hidden Exception pattern uses Execution Residue pattern as a technique to uncover such exceptions.

Most of Software Trace and Log Analysis Patterns are General Analysis Patterns that were devised and cataloged to structure the analysis of the diverse logs from different products and OS platforms3. For example, a specific data value common to both working and problem logs that helps to find out the missing information from the problem description can be generalized to Inter-Correlation analysis between the problem trace and Master Trace using Shared Point.

This partitioning is depicted in the following diagram:

Software Diagnostics Institute innovation is in devising and cataloging general problem and analysis patterns and providing some concrete analysis implementations on specific OS platforms such as Windows and Mac OS X.

1 Pattern-Oriented Software Forensics: A Foundation of Memory Forensics and Forensics of Things, page 13
2 Ibid., page 14
3 Malware Narratives: An Introduction, page 14