Software Diagnostics Library

“… the vital point for you to understand is that all” tracing “must be conducted with the creation of” solution “in mind. That is what must colour and control your selection of” tracing “events.”

Michael Allen, The Truth About Writing

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

One of the questions asked during Introduction to Pattern-Driven Software Problem Solving Webinar was how to map bugcheck codes to crash dump analysis patterns. I’m starting this post to provide a few initial mappings and plan to extend it later.

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

Memory Dump Analysis Services is working on the “Start It” button:

http://www.dumpanalysis.com/introducing-project-start

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

Memory Dump Analysis Services offers 5 volumes of Memory Dump Analysis Anthology (in PDF format) with a 50% discount until the end of June:

http://www.dumpanalysis.com/ultimate-memory-analysis-reference

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

Presentation Software Trace and Memory Dump Analysis: Patterns, Tools, Processes and Best Practices from E2E Virtualization Conference (13th of May, 2011) is available for download:

http://www.dumpanalysis.com/STMDA-materials

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

This is a forthcoming virtual event to learn analysis of blockages, delays, obstructions, preventions, and stoppages in victimware suffering from software defects and malware. Additional information on how to join will be available soon on the main portal page:

http://www.dumpanalysis.org/stoppages2011

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

Most of the time software trace messages coming from the same source code fragment (PLOT) contain invariant parts such as function and variable names, descriptions, and mutable parts such as pointer values and error codes. Message Invariant is a pattern useful for comparative analysis of several trace files where we are interested in message differences. For example, in one troubleshooting scenario certain objects were not created correctly for one user. We suspected a different object version was linked to a user profile. Separate application debug traces were recorded for each user and we could see version 0×4 for the problem user and 0×5 for all other normal users:

#    Module  PID  TID  Time         Message
[...]
2782 ModuleA 2124 5648 10:58:03.356 CreateObject: pObject 0×00A83D30 data ([…]) version 0×4
[…]

#    Module  PID  TID  Time         Message
[...]
4793 ModuleA 2376 8480 09:22:01.947 CreateObject: pObject 0×00BA4E20 data ([…]) version 0×5  
[…]

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

To model software behavior at application and system levels, test generative debugging scenarious and construct software defects using metaprogramming I started working on MdTL (Metadefect Template Library). Its consists of C++ templates for structural and behavioral patterns. The simplest examples include Threads<Spike> and Spike<Thread>. The template classes can be more complex, of course, utilizing the full power of C++, STL, and existing libraries like Boost. The unique and novel feature of this library is the inclusion of dual classes of behaviour such as Leak<>, Deadlock<>, Overflow<>, Residue<>, Exception<>, Contention<>, etc. parameterized by various structural memory classes like Process<>, Thread<>, Heap<>, Stack<>, Region<>, Buffer<>, etc. MdTL also includes classes to model software tracing and this will be used for simultaneous software trace and memory dump analysis case study in the forthcoming presentation. I also plan to extend this metaprogramming approach in the future to model malware analysis patterns by introducing Metamalware Template Library (MmTL).

Forthcoming parts will introduce template classes and examples.

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

The New School of Debugging places pattern-driven memory and software trace analysis as a solid foundation for any debugging methodology, processes, tools and techniques. Unified Debugging Patterns and Generative Debugging Framework are additional features of the new school. To highlight its essentials I’ve created this draft diagram:

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

This pattern is a kernel mode counterpart to Self-Diagnosis in user mode. It is just a collection of bugcheck codes where a problem is usually detected before corruption causes a fault, exception or trap. Typical example would be a detection of a failed assertion or corrupt structures such as:

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 8b79d078, The pool entry we were looking for within the page.
Arg3: 8b79d158, The next pool entry.
Arg4: 8a1c0004, (reserved)

More examples would be added in the forthcoming case studies.

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

Here we continue with Technology-Specific Subtrace pattern series started earlier with COM interface invocation example. In this part we consider dynamic memory allocation example in kernel space (kernel pool). Usually pool corruption is detected during pool memory allocation or release with a special bugcheck code, for example:

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 8b79d078, The pool entry we were looking for within the page.
Arg3: 8b79d158, The next pool entry.
Arg4: 8a1c0004, (reserved)

However, pool corruption might be deeper enough to trigger an access violation even before self-diagnosis. In such cases stack subtraces with functions like ExFreePoolWithTag might point to troubleshooting and debugging directions:

ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
An attempt was made to write to readonly memory. The guilty driver is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver’s name (Unicode string) is printed on the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: 00470044, Virtual address for the attempted write.
Arg2: 06d39025, PTE contents.
Arg3: aec0fb30, (reserved)
Arg4: 0000000a, (reserved)

TRAP_FRAME:  aec0fb30 -- (.trap 0xffffffffaec0fb30)
ErrCode = 00000003
eax=8ac12d38 ebx=8b700040 ecx=000001ff edx=00470040 esi=8ac12db8 edi=808b0b40
eip=808949e7 esp=aec0fba4 ebp=aec0fbf0 iopl=0 nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000  efl=00010202
nt!ExFreePoolWithTag+0x6a3:
808949e7 895a04          mov     dword ptr [edx+4],ebx ds:0023:00470044=????????

STACK_TEXT:
aec0faa0 80860121 000000be 00470044 06d39025 nt!KeBugCheckEx+0x1b
aec0fb18 8088e490 00000001 00470044 00000000 nt!MmAccessFault+0xb25
aec0fb18 808949e7 00000001 00470044 00000000 nt!KiTrap0E+0xdc
aec0fbf0 808d93b5 8ac12dc0 00000000 00000000 nt!ExFreePoolWithTag+0×6a3
aec0fc08 808cd304 e5ae5770 8ac12dc0 8aa77db0 nt!CmpFreePostBlock+0×4d
aec0fc3c 8082ea53 8ac12dc0 aec0fc88 aec0fc7c nt!CmpPostApc+0xde
aec0fc8c 80833eec 00000000 00000000 00000000 nt!KiDeliverApc+0xf9
aec0fcc4 808290bd aec0fd64 8099781c 0160fd44 nt!KiSwapThread+0×300
aec0fd0c 809978a0 00000001 00000000 f77275e0 nt!KeDelayExecutionThread+0×2ab
aec0fd54 8088b45c 00000000 0160fd74 0160fd9c nt!NtDelayExecution+0×84
aec0fd54 7c82847c 00000000 0160fd74 0160fd9c nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0160fd9c 00000000 00000000 00000000 00000000 0×7c82847c

1: kd> !pool 8ac12dc0
Pool page 8ac12dc0 region is Nonpaged pool
 8ac12000 size:  858 previous size:    0  (Allocated)  TWPG
 8ac12858 size:    8 previous size:  858  (Free)       ….
 8ac12860 size:   20 previous size:    8  (Allocated)  VadS
 8ac12880 size:    8 previous size:   20  (Free)       NtFs
 8ac12888 size:   20 previous size:    8  (Allocated)  VadS
 8ac128a8 size:   28 previous size:   20  (Allocated)  Ntfn
 8ac128d0 size:   30 previous size:   28  (Allocated)  Vad
 8ac12900 size:   40 previous size:   30  (Allocated)  Muta (Protected)
 8ac12940 size:   38 previous size:   40  (Allocated)  Sema (Protected)
 8ac12978 size:   40 previous size:   38  (Allocated)  Muta (Protected)
 8ac129b8 size:  270 previous size:   40  (Allocated)  Thre (Protected)
 8ac12c28 size:   40 previous size:  270  (Allocated)  Ntfr
 8ac12c68 size:   d0 previous size:   40  (Allocated)  DRIV
8ac12d38 is not a valid large pool allocation, checking large session pool…
8ac12d38 is freed (or corrupt) pool
Bad previous allocation size @8ac12d38, last size was 1a

***
*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
***
*** Use !poolval 8ac12000 for more details.
***

Pool page [ 8ac12000 ] is __inVALID.

Analyzing linked list...
[ 8ac12c68 --> 8ac12db8 (size = 0x150 bytes)]: Corrupt region
Scanning for single bit errors...

None found

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

Module Hint pattern is frequently observed in dynamic memory corruption incidents. It is similar to Execution Residue or String Parameter patterns were we have ASCII or UNICODE fragments providing troubleshooting and debugging hints. Module Hint is therefore a more specialized pattern where we can link module names to raw data. For example, a kernel memory dump saved after the detected pool corruption shows P12345.DLL module name in a pool entry that can provide a link to the corresponding functionally to be reconfigured or removed:

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 8b79d078, The pool entry we were looking for within the page.
Arg3: 8b79d158, The next pool entry.
Arg4: 8a1c0004, (reserved)

STACK_TEXT: 
b3e0aa4c 808947bb 00000019 00000020 8b79d078 nt!KeBugCheckEx+0x1b
b3e0aab4 b368c00f 8b79d080 00000000 00000000 nt!ExFreePoolWithTag+0×477
b3e0aac4 b366c68e 8b79d080 00000000 00000000 DriverA!MemFree+0xf
[…]
b3e0ac44 8081e0c3 808f77c9 b3e0ac64 808f77c9 nt!IovCallDriver+0×112
b3e0ac50 808f77c9 8a8eef60 8b6862a8 8a8eeef0 nt!IofCallDriver+0×13
b3e0ac64 808f856b 8ce456b0 8a8eeef0 8b6862a8 nt!IopSynchronousServiceTail+0×10b
b3e0ad00 808f109a 000009dc 00000000 00000000 nt!IopXxxControlFile+0×5e5
b3e0ad34 8088b45c 000009dc 00000000 00000000 nt!NtDeviceIoControlFile+0×2a
b3e0ad34 7c82847c 000009dc 00000000 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
00f5fb18 00000000 00000000 00000000 00000000 0×7c82847c

2: kd> !pool 8b79d080
Pool page 8b79d080 region is Unknown
 8b79d000 size:   30 previous size:    0  (Allocated)  FSfm
 8b79d030 size:   28 previous size:   30  (Allocated)  VadS
 8b79d058 size:   20 previous size:   28  (Allocated)  ReEv
*8b79d078 size:   e0 previous size:   20  (Allocated) *DRIV 
  Owning component : Unknown (update pooltag.txt)
8b79d158 is not a valid large pool allocation, checking large session pool…
8b79d158 is freed (or corrupt) pool
Bad previous allocation size @8b79d158, last size was 1c

***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFFFFF8B79D158)
***
*** Use !poolval 8b79d000 for more details.
***

2: kd> dc 8b79d078
8b79d078  [...] ..DRIV  ......AP
8b79d088  [...] P12345.DLL……
8b79d098  […] …..<%n……..
8b79d0a8  […] ….$…:.F…X.
[…]

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

Very simple methodology summarized in just 3 words applicable to any problem solving domain and its activities including software troubleshooting and debugging:

Artifacts. Checklists. Patterns.

As an example of checklists and patterns please see these 3 presentations related to memory dump and software trace artifacts:

Introduction to Pattern-Driven Software Problem Solving

Fundamentals of Complete Crash and Hang Memory Dump Analysis

Pattern-Driven Memory Dump Analysis 

I’m now working on a detailed presentation of this methodology. 

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

A page to reference all different kinds of .NET related patterns is necessary, so I created this post:

• CLR Thread
• Managed Code Exception
• Nested Exceptions (managed code)
• Mixed Exception
• Memory Leak (.NET heap)
• JIT Code (.NET)
• Managed Stack Trace
• Multiple Exceptions (managed space)
• Version-Specific Extension
• Caller-n-Callee
• Technology-Specific Subtrace (JIT .NET code)
• Inline Function Optimization (managed code)
• Annotated Disassembly (JIT .NET code)
• Handled Exception (.NET CLR)
• Execution Residue (managed space)
• Deadlock (managed space)
• Duplicate Extension
• Stack Trace Collection (managed space)
• Dynamic Memory Corruption (managed heap)
• Special Thread (.NET CLR)
• Wait Chain (CLR monitors)
• Distributed Exception (managed code)
• Object Distribution Anomaly (.NET heap)
• High Contention (.NET heap)
• Deadlock (.NET Finalizer)
• Hidden Exception (managed space)
• Rough Stack Trace (managed space)
• Saved Exception Context (.NET)
• Stack Overflow (managed space)

I’ll update it as soon as I add more similar patterns.

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

Imagine a pattern-driven crash analysis report (car) when you need it: at the very moment of a crash, just in time! And the car drives you to a problem resolution. Imagine also a periodic pattern-driven just-in-time memory space analysis (JIT MSA) that provides you instant intelligent reports on what’s going on inside memory while your application, service or system is running! This is a forthcoming optional client side part of CARE (Crash Analysis Report Environment) which is being developed by Memory Dump Analysis Services engineering team under the leadership of Alexey Golikov. Combined with generative debugging techniques both client and server parts form a complete unique enterprise crash and hang analysis solution suitable for development and production environments. Stay tuned for further exciting updates.

PS. The car drives on a road to the first fault software problem solving.

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

I’m pleased to announce that MDAA, Volume 5 is available in PDF format:

www.dumpanalysis.org/Memory+Dump+Analysis+Anthology+Volume+5

It 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

Its table of contents is available here:

www.dumpanalysis.org/MDAA/MDA-Anthology-V5-TOC.pdf

Paperback and hardcover versions should be available in a week or two. I also started working on Volume 6 that should be available in November-December.

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

Followed by my search for a periodic table of software defects I came up with a novel approach called Generative Debugging partially borrowed from principles and parameters generative linguistics framework. For debugging and post-construction software problem solving purposes we have Behavioral Principles and Structural Parameters. The parameters allow us to describe existing and even generate new software defects (I’m also considering Structural Principles and Behavioural Parameters but whether this is fruitful needs to be explored and seen. We may also consider the name “generative debugging” as a “naming” counterpart to software construction problem solving called generative programming. So the former could also be used to generate problem solutions faster in automatic fashion. Both, in the future, may be combined into a unified generative software problem solving.

As a first example, consider an application functional hang with a thread blocked by a pending I/O request packet (IRP). It is composed from general behavioral principle of blocked (or unresponsive) activity and structural parameters including Thread and IRP.

In the following parts many software incidents will be explored from this generative perspective.

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

I’m to present pattern-driven software trace analysis with examples from application and desktop delivery environments featuring Memory Dump Analysis Services at the forthcoming E2E Virtualization Conference (PubForum) in Dublin on 13th of May, 2011. Topics include a case study covering simultaneous analysis of software traces and memory dumps.

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

Adjoint Thread invariants like PID can be reused giving rise to curious CDF (ETW) traces where two separate execution entities are glued together in one trace. For example, in one trace we see AppA and AppB sharing the same PID

#      Module  PID  TID   Time         Message
[…]
242583 ProcMon 5492 9476  11:04:33.398 LoadImageEvent for ImageName: …\AppA.exe PID: 5492
256222 ProcMon 5492 9476  11:04:50.036 ProcessDestroyEvent for PPID: 12168 PID: 5492 
274887 ProcMon 5492 10288 11:05:18.235 LoadImageEvent for ImageName: …\AppB.exe PID: 5492 
[…]

Other similar examples might include different instances of components sharing the same name, source code or even, in general, periodic tracing sessions appended to the end of the same trace file although we are thinking that the latter should be a separate pattern. We named this pattern Glued Activity by an analogy of different thread strings glued together (in general, manifiolds glued along their boundaries). Another name might be along the line of adjoint thread ID reuse (ATID Reuse).

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

The first Webinar to start an in-depth discussion of a uniform methodology and tools for analysis of crashes, hangs, and other types of abnormal software behaviour in cloud environments.

Memory Dump Analysis Services (DumpAnalysis.com) organizes a free Webinar

Date: 13th of June 2011
Time: 18:45 (BST) 13:45 (EST) 10:45 (PST)
Duration: 60 minutes

Topics include:

• What’s old
• What’s new
• Orbifold memory spaces
• Methodology and best practices
• Cloud-specific patterns
• Hands-on exercises

Prerequisites: working knowledge of basic memory dump analysis or live debugging.

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

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