Software Diagnostics Library

Network Trace Analysis Patterns (Part 1)

July 19th, 2012

After some thinking I’ve decided to apply software trace analysis pattern approach to network trace analysis which lacks a unified pattern language. Here I consider a network trace as essentially a software trace where packet headers represent software trace messages coupled with associated transmitted data:

Since we have a trace message stream formatted by a network trace visualization tool we can apply most if not all trace analysis patterns for diagnostics including software narratology for interpretation, discourse and different representations. We provide a few trivial examples here and more in subsequent parts. The first example is Discontinuity pattern:

Other similar patterns are No Activity, Truncated Trace and Time Delta. The second example is Anchor Messages:

Additional example there include Significant Event and Bifurcation Point patterns. Layered protocols are represented through Embedded Message pattern (to be described and added to the pattern list soon). Such traces can be filtered for their embedded protocol headers and therefore naturally represent Adjoint Thread pattern (for the more detailed description of adjoint threads as extension of multithreading please see the article What is an Adjoint Thread):

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

Posted in Network Trace Analysis Patterns, Software Behavior Patterns, Software Diagnostics, Software Diagnostics Pattern Language, Software Diagnostics Patterns, Software Narratology, Software Trace Analysis | No Comments »

Crash Dump Analysis Patterns (Part 78a, Mac OS X)

July 18th, 2012

This is a Mac OS X / GDB counterpart to Divide by Zero (user mode) pattern previously described for Windows platforms:

(gdb) bt #0 0×000000010d3ebe9e in bar (a=1, b=0) #1 0×000000010d3ebec3 in foo () #2 0×000000010d3ebeeb in main (argc=1, argv=0×7fff6cfeab18)

(gdb) x/i 0×000000010d3ebe9e 0×10d3ebe9e : idiv %esi

(gdb) info r rsi rsi 0×0 0

The modeling application source code:

int bar(int a, int b)

{

return a/b;

}

int foo()

{

return bar(1,0);

}

int main(int argc, const char * argv[])

{

return foo();

}

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

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

Posted in Core Dump Analysis, Crash Dump Patterns, GDB for WinDbg Users, Mac Crash Corner, Mac OS X, x64 Mac OS X | No Comments »

Crash Dump Analysis Patterns (Part 16b, Mac OS X)

July 17th, 2012

This is a Mac OS X / GDB counterpart to Stack Overflow (user mode) pattern previously described for Windows platforms:

(gdb) bt 10 #0 0x0000000105dafea8 in bar (i=0) #1 0x0000000105dafeb9 in bar (i=262102) #2 0x0000000105dafeb9 in bar (i=262101) #3 0x0000000105dafeb9 in bar (i=262100) #4 0x0000000105dafeb9 in bar (i=262099) #5 0x0000000105dafeb9 in bar (i=262098) #6 0x0000000105dafeb9 in bar (i=262097) #7 0x0000000105dafeb9 in bar (i=262096) #8 0x0000000105dafeb9 in bar (i=262095) #9 0x0000000105dafeb9 in bar (i=262094) (More stack frames follow...)

There are at least 262,102 frames so we don’t attempt to list them all. What we’d like to do is to get stack trace boundaries from the list of sections based on the current stack pointer address and dump the upper part of it (the stack grows from higher addresses to the lower ones) to get bottom initial stack traces:

(gdb) x $rsp 0×7fff651aeff0: 0×00000000

Because this is a stack overflow we expect RSP went out of page bounds so we expect the lowest address being 0×7fff651af000.

(gdb) maint info sections [...] Core file: `/cores/core.2763', file type mach-o-le. [...] 0x0000000105e00000->0x0000000105f00000 at 0x00035000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS 0x00007fff619af000->0x00007fff651af000 at 0x00135000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS 0×00007fff651af000->0×00007fff659af000 at 0×03935000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS 0×00007fff659af000->0×00007fff659e4000 at 0×04135000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS 0×00007fff659e4000->0×00007fff659e6000 at 0×0416a000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS […]

(gdb) x/250a 0×00007fff659af000-2000 0×7fff659ae830: 0×0 0×1500000000 0×7fff659ae840: 0×7fff659ae860 0×105dafeb9 <bar+25> 0×7fff659ae850: 0×0 0×1400000000 0×7fff659ae860: 0×7fff659ae880 0×105dafeb9 <bar+25> 0×7fff659ae870: 0×0 0×1300000000 0×7fff659ae880: 0×7fff659ae8a0 0×105dafeb9 <bar+25> 0×7fff659ae890: 0×0 0×1200000000 0×7fff659ae8a0: 0×7fff659ae8c0 0×105dafeb9 <bar+25> 0×7fff659ae8b0: 0×0 0×1100000000 0×7fff659ae8c0: 0×7fff659ae8e0 0×105dafeb9 <bar+25> 0×7fff659ae8d0: 0×0 0×1000000000 0×7fff659ae8e0: 0×7fff659ae900 0×105dafeb9 <bar+25> 0×7fff659ae8f0: 0×0 0xf00000000 0×7fff659ae900: 0×7fff659ae920 0×105dafeb9 <bar+25> 0×7fff659ae910: 0×0 0xe00000000 0×7fff659ae920: 0×7fff659ae940 0×105dafeb9 <bar+25> 0×7fff659ae930: 0×0 0xd00000000 0×7fff659ae940: 0×7fff659ae960 0×105dafeb9 <bar+25> 0×7fff659ae950: 0×0 0xc00000000 0×7fff659ae960: 0×7fff659ae980 0×105dafeb9 <bar+25> 0×7fff659ae970: 0×0 0xb00000000 0×7fff659ae980: 0×7fff659ae9a0 0×105dafeb9 <bar+25> 0×7fff659ae990: 0×0 0xa00000000 0×7fff659ae9a0: 0×7fff659ae9c0 0×105dafeb9 <bar+25> 0×7fff659ae9b0: 0×0 0×900000000 0×7fff659ae9c0: 0×7fff659ae9e0 0×105dafeb9 <bar+25> 0×7fff659ae9d0: 0×0 0×800000000 0×7fff659ae9e0: 0×7fff659aea00 0×105dafeb9 <bar+25> 0×7fff659ae9f0: 0×0 0×700000000 0×7fff659aea00: 0×7fff659aea20 0×105dafeb9 <bar+25> 0×7fff659aea10: 0×0 0×600000000 0×7fff659aea20: 0×7fff659aea40 0×105dafeb9 <bar+25> 0×7fff659aea30: 0×0 0×5659b9fe0 0×7fff659aea40: 0×7fff659aea60 0×105dafeb9 <bar+25 0×7fff659aea50: 0×7fff659aea70 0×4659bd31f 0×7fff659aea60: 0×7fff659aea80 0×105dafeb9 <bar+25> 0×7fff659aea70: 0×7fff659aeaf0 0×3659b031a 0×7fff659aea80: 0×7fff659aeaa0 0×105dafeb9 <bar+25> 0×7fff659aea90: 0×7fff659af5c0 0×200000000 0×7fff659aeaa0: 0×7fff659aeac0 0×105dafeb9 <bar+25> 0×7fff659aeab0: 0×100000000 0×1659aeb18 0×7fff659aeac0: 0×7fff659aead0 0×105dafece <foo+14> 0×7fff659aead0: 0×7fff659aeaf0 0×105dafeeb <main+27> 0×7fff659aeae0: 0×7fff659aeb18 0×1 —Type to continue, or q to quit— 0×7fff659aeaf0: 0×7fff659aeb08 0×105dafe94 <start+52> 0×7fff659aeb00: 0×0 0×0 […] 0×7fff659aeff0: 0×3139336561303363 0×316235

Interesting if we set the lowest frame down and try to get register info GDB core dumps:

(gdb) frame 262102 #262102 0x0000000105dafeb9 in bar (i=1) 13 bar(i+1); (gdb) info r Segmentation fault: 11 (core dumped)

Looking its core dump show that it also experienced stack overflow:

(gdb) bt #0 0x00007fff8c1bacf0 in __sfvwrite () #1 0x00007fff8c189947 in __vfprintf () #2 0x00007fff8c184edb in vsnprintf_l () #3 0x00007fff8c1566be in __sprintf_chk () #4 0x000000010bd14d15 in print_displacement () #5 0x000000010bd10ddf in OP_E () #6 0x000000010bd13f9b in print_insn () #7 0x000000010bc164ce in length_of_this_instruction () #8 0x000000010bc9e296 in x86_analyze_prologue () #9 0x000000010bc9f1f3 in x86_frame_prev_register () #10 0x000000010bc91d70 in frame_register_unwind () #11 0x000000010bc92015 in frame_unwind_register () #12 0x000000010bc91d70 in frame_register_unwind () #13 0x000000010bc92015 in frame_unwind_register () #14 0x000000010bc91d70 in frame_register_unwind () #15 0x000000010bc92015 in frame_unwind_register () #16 0x000000010bc91d70 in frame_register_unwind () #17 0x000000010bc92015 in frame_unwind_register () #18 0x000000010bc91d70 in frame_register_unwind () #19 0x000000010bc92015 in frame_unwind_register () #20 0x000000010bc91d70 in frame_register_unwind () #21 0x000000010bc92015 in frame_unwind_register () #22 0x000000010bc91d70 in frame_register_unwind () #23 0x000000010bc92015 in frame_unwind_register () #24 0x000000010bc91d70 in frame_register_unwind () #25 0x000000010bc92015 in frame_unwind_register () #26 0x000000010bc91d70 in frame_register_unwind () #27 0x000000010bc92015 in frame_unwind_register () #28 0x000000010bc91d70 in frame_register_unwind () #29 0x000000010bc92015 in frame_unwind_register () #30 0x000000010bc91d70 in frame_register_unwind () #31 0x000000010bc92015 in frame_unwind_register () #32 0x000000010bc91d70 in frame_register_unwind () #33 0x000000010bc92015 in frame_unwind_register () #34 0x000000010bc91d70 in frame_register_unwind () #35 0x000000010bc92015 in frame_unwind_register () #36 0x000000010bc91d70 in frame_register_unwind () #37 0x000000010bc92015 in frame_unwind_register () #38 0x000000010bc91d70 in frame_register_unwind () #39 0x000000010bc92015 in frame_unwind_register () #40 0x000000010bc91d70 in frame_register_unwind () #41 0x000000010bc92015 in frame_unwind_register () #42 0x000000010bc91d70 in frame_register_unwind () #43 0x000000010bc92015 in frame_unwind_register ()

The source code of our modeling application:

void bar(int i)

{

bar(i+1);

}

void foo()

{

bar(1);

}

int main(int argc, const char * argv[])

{

foo();

return 0;

}

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

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

Posted in Core Dump Analysis, Crash Dump Patterns, GDB for WinDbg Users, Mac Crash Corner, Mac OS X, x64 Mac OS X | No Comments »

Module Patterns

July 15th, 2012

A page to reference all different kinds of module and component related patterns is necessary, so I created this post:

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

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

Posted in Core Dump Analysis, Crash Dump Analysis, Crash Dump Patterns, Debugging, Malware Analysis | 2 Comments »

Crash Dump Analysis Patterns (Part 179)

July 15th, 2012

When looking at the module list (lmv), searching for modules (.imgscan) or examining the particular module (!address, !dh) we may notice one of them as Deviant Module. The deviation may be in (but not limited to as anything is possible):

- suspicious module name

- suspicious protection

- suspicious module load address

0:005> .imgscan MZ at 00040000, prot 00000040, type 00020000 - size 1d000 MZ at 00340000, prot 00000002, type 01000000 - size 9c000 Name: iexplore.exe MZ at 02250000, prot 00000002, type 00040000 - size 2000 MZ at 023b0000, prot 00000002, type 01000000 - size b000 Name: msimtf.dll MZ at 03f80000, prot 00000002, type 00040000 - size 2000 MZ at 10000000, prot 00000004, type 00020000 - size 5000 Name: screens_dll.dll MZ at 16080000, prot 00000002, type 01000000 - size 25000 Name: mdnsNSP.dll MZ at 6ab50000, prot 00000002, type 01000000 - size 26000 Name: DSSENH.dll MZ at 6b030000, prot 00000002, type 01000000 - size 5b0000 Name: MSHTML.dll MZ at 6ba10000, prot 00000002, type 01000000 - size b4000 Name: JSCRIPT.dll MZ at 6cec0000, prot 00000002, type 01000000 - size 1b000 Name: CRYPTNET.dll MZ at 6d260000, prot 00000002, type 01000000 - size e000 Name: PNGFILTER.DLL MZ at 6d2f0000, prot 00000002, type 01000000 - size 29000 Name: msls31.dll MZ at 6d700000, prot 00000002, type 01000000 - size 30000 Name: MLANG.dll MZ at 6d740000, prot 00000002, type 01000000 - size 4d000 Name: SSV.DLL MZ at 6d7b0000, prot 00000002, type 01000000 - size c000 Name: ImgUtil.dll MZ at 6ddb0000, prot 00000002, type 01000000 - size 2f000 Name: iepeers.DLL MZ at 6df20000, prot 00000002, type 01000000 - size 33000 Name: IEShims.dll MZ at 6eb80000, prot 00000002, type 01000000 - size a94000 Name: IEFRAME.dll MZ at 703b0000, prot 00000002, type 01000000 - size 53000 Name: SWEEPRX.dll MZ at 70740000, prot 00000002, type 01000000 - size 40000 Name: SWEEPRX.dll MZ at 725a0000, prot 00000002, type 01000000 - size 12000 Name: PNRPNSP.dll MZ at 725d0000, prot 00000002, type 01000000 - size 8000 Name: WINRNR.dll MZ at 725e0000, prot 00000002, type 01000000 - size 136000 Name: MSXML3.dll MZ at 72720000, prot 00000002, type 01000000 - size c000 Name: wshbth.dll MZ at 72730000, prot 00000002, type 01000000 - size f000 Name: NAPINSP.dll MZ at 72890000, prot 00000002, type 01000000 - size 6000 Name: SensApi.dll MZ at 72ec0000, prot 00000002, type 01000000 - size 42000 Name: WINSPOOL.DRV MZ at 734b0000, prot 00000002, type 01000000 - size 6000 Name: rasadhlp.dll MZ at 736b0000, prot 00000002, type 01000000 - size 85000 Name: COMCTL32.dll MZ at 73ac0000, prot 00000002, type 01000000 - size 7000 Name: MIDIMAP.dll MZ at 73ae0000, prot 00000002, type 01000000 - size 14000 Name: MSACM32.dll MZ at 73b00000, prot 00000002, type 01000000 - size 66000 Name: audioeng.dll MZ at 73c30000, prot 00000002, type 01000000 - size 9000 Name: MSACM32.DRV MZ at 73c60000, prot 00000002, type 01000000 - size 21000 Name: AudioSes.DLL MZ at 73c90000, prot 00000002, type 01000000 - size 2f000 Name: WINMMDRV.dll MZ at 74290000, prot 00000002, type 01000000 - size bb000 Name: PROPSYS.dll MZ at 74390000, prot 00000002, type 01000000 - size f000 Name: nlaapi.dll MZ at 743a0000, prot 00000002, type 01000000 - size 4000 Name: ksuser.dll MZ at 74430000, prot 00000002, type 01000000 - size 15000 Name: Cabinet.dll MZ at 74450000, prot 00000002, type 01000000 - size 3d000 Name: OLEACC.dll MZ at 74490000, prot 00000002, type 01000000 - size 1ab000 Name: gdiplus.dll MZ at 74640000, prot 00000002, type 01000000 - size 28000 Name: MMDevAPI.DLL MZ at 74670000, prot 00000002, type 01000000 - size 32000 Name: WINMM.dll MZ at 746b0000, prot 00000002, type 01000000 - size 31000 Name: TAPI32.dll MZ at 749e0000, prot 00000002, type 01000000 - size 19e000 Name: COMCTL32.dll MZ at 74b80000, prot 00000002, type 01000000 - size 7000 Name: AVRT.dll MZ at 74ba0000, prot 00000002, type 01000000 - size 4a000 Name: RASAPI32.dll MZ at 74ce0000, prot 00000002, type 01000000 - size 3f000 Name: UxTheme.dll MZ at 74de0000, prot 00000002, type 01000000 - size 2d000 Name: WINTRUST.dll MZ at 74ea0000, prot 00000002, type 01000000 - size 14000 Name: rasman.dll MZ at 74f70000, prot 00000002, type 01000000 - size c000 Name: rtutils.dll MZ at 74f80000, prot 00000002, type 01000000 - size 5000 Name: WSHTCPIP.dll MZ at 74fb0000, prot 00000002, type 01000000 - size 21000 Name: NTMARTA.dll MZ at 75010000, prot 00000002, type 01000000 - size 3b000 Name: RSAENH.dll MZ at 75050000, prot 00000002, type 01000000 - size 5000 Name: MSIMG32.dll MZ at 75060000, prot 00000002, type 01000000 - size 15000 Name: GPAPI.dll MZ at 750a0000, prot 00000002, type 01000000 - size 46000 Name: SCHANNEL.dll MZ at 752b0000, prot 00000002, type 01000000 - size 3b000 Name: MSWSOCK.dll MZ at 75370000, prot 00000002, type 01000000 - size 45000 Name: bcrypt.dll MZ at 753f0000, prot 00000002, type 01000000 - size 5000 Name: WSHIP6.dll MZ at 75400000, prot 00000002, type 01000000 - size 8000 Name: VERSION.dll MZ at 75420000, prot 00000002, type 01000000 - size 7000 Name: CREDSSP.dll MZ at 75430000, prot 00000002, type 01000000 - size 35000 Name: ncrypt.dll MZ at 75480000, prot 00000002, type 01000000 - size 22000 Name: dhcpcsvc6.DLL MZ at 754b0000, prot 00000002, type 01000000 - size 7000 Name: WINNSI.DLL MZ at 754c0000, prot 00000002, type 01000000 - size 35000 Name: dhcpcsvc.DLL MZ at 75500000, prot 00000002, type 01000000 - size 19000 Name: IPHLPAPI.DLL MZ at 75590000, prot 00000002, type 01000000 - size 3a000 Name: slc.dll MZ at 755d0000, prot 00000002, type 01000000 - size f2000 Name: CRYPT32.dll MZ at 75740000, prot 00000002, type 01000000 - size 12000 Name: MSASN1.dll MZ at 75760000, prot 00000002, type 01000000 - size 11000 Name: SAMLIB.dll MZ at 75780000, prot 00000002, type 01000000 - size 76000 Name: NETAPI32.dll MZ at 75800000, prot 00000002, type 01000000 - size 2c000 Name: DNSAPI.dll MZ at 75a70000, prot 00000002, type 01000000 - size 5f000 Name: sxs.dll MZ at 75ad0000, prot 00000002, type 01000000 - size 2c000 Name: apphelp.dll MZ at 75b30000, prot 00000002, type 01000000 - size 14000 Name: Secur32.dll MZ at 75b50000, prot 00000002, type 01000000 - size 1e000 Name: USERENV.dll MZ at 75c90000, prot 00000002, type 01000000 - size 7000 Name: PSAPI.DLL MZ at 75ca0000, prot 00000002, type 01000000 - size c3000 Name: RPCRT4.dll MZ at 75d70000, prot 00000002, type 01000000 - size 73000 Name: COMDLG32.dll MZ at 75df0000, prot 00000002, type 01000000 - size 9000 Name: LPK.dll MZ at 75e00000, prot 00000002, type 01000000 - size dc000 Name: KERNEL32.dll MZ at 75ee0000, prot 00000002, type 01000000 - size aa000 Name: msvcrt.dll MZ at 75f90000, prot 00000002, type 01000000 - size 1e8000 Name: iertutil.dll MZ at 76180000, prot 00000002, type 01000000 - size 29000 Name: imagehlp.dll MZ at 761b0000, prot 00000002, type 01000000 - size 6000 Name: NSI.dll MZ at 761c0000, prot 00000002, type 01000000 - size 84000 Name: CLBCatQ.DLL MZ at 76250000, prot 00000002, type 01000000 - size 49000 Name: WLDAP32.dll MZ at 762a0000, prot 00000002, type 01000000 - size c6000 Name: ADVAPI32.dll MZ at 76370000, prot 00000002, type 01000000 - size 4b000 Name: GDI32.dll MZ at 763c0000, prot 00000002, type 01000000 - size 59000 Name: SHLWAPI.dll MZ at 76420000, prot 00000002, type 01000000 - size e6000 Name: WININET.dll MZ at 76510000, prot 00000002, type 01000000 - size b10000 Name: SHELL32.dll MZ at 77020000, prot 00000002, type 01000000 - size 145000 Name: ole32.dll MZ at 77170000, prot 00000002, type 01000000 - size 7d000 Name: USP10.dll MZ at 771f0000, prot 00000002, type 01000000 - size 8d000 Name: OLEAUT32.dll MZ at 77280000, prot 00000002, type 01000000 - size 18a000 Name: SETUPAPI.dll MZ at 77410000, prot 00000002, type 01000000 - size 9d000 Name: USER32.dll MZ at 774b0000, prot 00000002, type 01000000 - size 133000 Name: urlmon.dll MZ at 775f0000, prot 00000002, type 01000000 - size 127000 Name: ntdll.dll MZ at 77720000, prot 00000002, type 01000000 - size 3000 Name: Normaliz.dll MZ at 77730000, prot 00000002, type 01000000 - size 2d000 Name: WS2_32.dll MZ at 77760000, prot 00000002, type 01000000 - size 1e000 Name: IMM32.dll MZ at 77780000, prot 00000002, type 01000000 - size c8000 Name: MSCTF.dll MZ at 7c340000, prot 00000002, type 01000000 - size 56000 Name: MSVCR71.dll

0:005> !address 00040000 Usage: <unclassified> Allocation Base: 00040000 Base Address: 00040000 End Address: 0005d000 Region Size: 0001d000 Type: 00020000 MEM_PRIVATE State: 00001000 MEM_COMMIT Protect: 00000040 PAGE_EXECUTE_READWRITE

0:005> !address 10000000 Usage: <unclassified> Allocation Base: 10000000 Base Address: 10000000 End Address: 10001000 Region Size: 00001000 Type: 00020000 MEM_PRIVATE State: 00001000 MEM_COMMIT Protect: 00000004 PAGE_READWRITE

- suspicious text inside

See this case study for an example.

- suspicious import table (screen grabbing) or its absence (dynamic imports)

0:005> !dh 10000000 [...] 2330 [ 50] address [size] of Export Directory 20E0 [ 78] address [size] of Import Directory 0 [ 0] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 4000 [ 34] address [size] of Base Relocation Directory 2060 [ 1C] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 0 [ 0] address [size] of Load Configuration Directory 0 [ 0] address [size] of Bound Import Directory 2000 [ 58] address [size] of Import Address Table Directory 0 [ 0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory […]

0:005> dps 10000000+2000 10000000+2000+58 10002000 76376101 gdi32!CreateCompatibleDC 10002004 763793d6 gdi32!StretchBlt 10002008 76377461 gdi32!CreateDIBSection 1000200c 763762a0 gdi32!SelectObject 10002010 00000000 10002014 75e4a411 kernel32!lstrcmpW 10002018 75e440aa kernel32!VirtualFree 1000201c 75e4ad55 kernel32!VirtualAlloc 10002020 00000000 10002024 77429ced user32!ReleaseDC 10002028 77423ba7 user32!NtUserGetWindowDC 1000202c 77430e21 user32!GetWindowRect 10002030 00000000 10002034 744a75e9 GdiPlus!GdiplusStartup 10002038 744976dd GdiPlus!GdipSaveImageToStream 1000203c 744cdd38 GdiPlus!GdipGetImageEncodersSize 10002040 744971cf GdiPlus!GdipDisposeImage 10002044 744a8591 GdiPlus!GdipCreateBitmapFromHBITMAP 10002048 744cdbae GdiPlus!GdipGetImageEncoders 1000204c 00000000 10002050 7707d51b ole32!CreateStreamOnHGlobal 10002054 00000000 10002058 00000000

0:000> !dh 012a0000 [...] 0 [ 0] address [size] of Export Directory 0 [ 0] address [size] of Import Directory 0 [ 0] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 8000 [ FC] address [size] of Base Relocation Directory 4000 [ 1C] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 0 [ 0] address [size] of Load Configuration Directory 0 [ 0] address [size] of Bound Import Directory 0 [ 0] address [size] of Import Address Table Directory 0 [ 0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory […]

- suspicious path names

Age: 7, Pdb: d:\work\BekConnekt\Client_src_code_New\Release\Blackjoe_new.pdb

Debug Directories(1) Type Size Address Pointer cv 46 2094 894 Format: RSDS, guid, 1, C:\MyWork\screens_dll\Release\screens_dll.pdb

- suspicious image path (although could be just dynamic code generation for .NET assemblies)

- uninitialized image resources

0:002> lmv m C6DC start end module name 012a0000 012a9000 C6DC C (no symbols) Loaded symbol image file: C6DC.tmp Image path: C:\Users\User\AppData\Local\Temp\C6DC.tmp Image name: C6DC.tmp Timestamp: Sun May 30 20:18:32 2010 (4C02BA08) CheckSum: 00000000 ImageSize: 00009000 File version: 0.0.0.0 Product version: 0.0.0.0 File flags: 0 (Mask 0) File OS: 0 Unknown Base File type: 0.0 Unknown File date: 00000000.00000000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

- suspicious (small) image size

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

Posted in Core Dump Analysis, Crash Dump Analysis, Crash Dump Patterns, Debugging, Malware Analysis, Victimware, Victimware Analysis | 2 Comments »

Software Diagnostics Services

July 13th, 2012

For some time I was struggling with finding a good name for memory dump and software trace analysis activities. The name Memoretics I use for the science of memory dump analysis (that also incorporates software traces) seems not so good to describe the whole practical activity that should be transparent to everyone in IT. Fortunately, I timely understood that all these activities constitute the essence of software diagnostics that previously lacked any solid foundation. Thus, Software Diagnostics Institute was reborn from the previous Crash Dump Analysis Portal. This institute does pure and applied research and scientific activities and in recent years was funded mainly from OpenTask publisher and recently from Memory Dump Analysis Services. The latter company also recognized that the broadening of its commercial activities requires a new name. So, Software Diagnostics Services was reborn:

The First Comprehensive Software Diagnostics Service

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

Posted in Announcements, Cloud Memory Dump Analysis, Complete Memory Dump Analysis, Core Dump Analysis, Crash Analysis Report Environment (CARE), Crash Dump Analysis, Debugging, Debugging Bureau, Debugging Industry, Debugging Methodology, Debugging Today, Debugging Trends, Education, Education and Research, Escalation Engineering, Event Tracing for Windows (ETW), First Fault Software Diagnostics, Generative Debugging, JIT Crash Analysis, JIT Memory Space Analysis, Java Debugging, Kernel Development, Kernel Memory Dump Analysis, Linux Crash Corner, MFC Debugging, Mac Crash Corner, Mac OS X, Malware Analysis, Memoretics, Memory Analysis Forensics and Intelligence, Memory Analysis Report System, Memory Dump Analysis Methodology, Memory Dump Analysis Services, Minidump Analysis, New Debugging School, Pattern-Driven Debugging, Pattern-Driven Software Support, Performance Monitoring, Root Cause Analysis, SQL Debugging, Security, Software Debugging Services, Software Diagnostics, Software Diagnostics Institute, Software Diagnostics Services, Software Engineering, Software Problem Solving, Software Technical Support, Software Trace Analysis, Software Trace Analysis Report Environment (STARE), Tools, Training and Seminars, Troubleshooting Methodology, Unified Software Diagnostics, Windows 7, Windows 8, Windows Azure, Windows Mobile, Windows Server 2008, Windows System Administration, x64 Mac OS X, x64 Windows | No Comments »

Software Trace Diagrams (STDiagrams)

July 3rd, 2012

When depicting trace analysis patterns I used two-dimensional diagrams based on CDF (ETW) traces such as this one for a bifurcation point:

While working today on a new pattern I needed a new expressive way to graphically illustrate the same idea of trace bifurcation points but without too much drawing. Traces from particle chambers and scattering diagrams came to my imagination after draw the first few diagrams illustrating bifurcation points:

Time directional arrow end can be omitted:

Trace variation after a bifurcation point can be indicated by angle partition:

The case when a variation also happens before is illustrated on this diagram:

and the case with several bifurcations:

Are N-bifurcations like on the diagram below possible?

Yes, they are, if the course of execution depends on some non-binary trace message parameter such as a loaded module that implements a required interface differently.

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

Posted in CDF Analysis Tips and Tricks, Event Tracing for Windows (ETW), Science of Software Tracing, Software Narratology, Software Trace Analysis, Software Trace Diagramming, Software Trace Visualization, Trace Analysis Patterns | 1 Comment »

Architecture of Process Memory Dump Capture Done Right

July 2nd, 2012

Sometimes I get requests to review application memory dump capture design. Of course, such requests usually come only when such designs don’t work or there are problems with loading saved crash dumps. The common blueprint of such architectures is a top level exception handler that use some API do capture and save process memory state. However, such designs forget why separate processed were introduced in the first place: to guard process memory space of different unrelated tasks (for related tasks there are threads). The data of the module (and its thread state) that does process memory capture may also be corrupt. The right design would be to show a message box with an information on how to use external process memory dumper such as Task Manager. If we need an automation then the right thing is to rely on WER features. Let separate processes do their work in separate spaces.

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

Posted in Core Dump Analysis, Debugging, Software Architecture, Software Diagnostics, Software Engineering | No Comments »

Crash Dump Analysis Patterns (Part 178)

June 27th, 2012

One of the frequent problems is an access violation at an address that belongs to Unloaded Module. Here’s an example that recently happened on our machine during an auto-update of the popular software package so we immediately attached a debugger after seeing WER dialog box:

0:000> ~*k

. 0 Id: bc8.bcc Suspend: 1 Teb: 7efdd000 Unfrozen ChildEBP RetAddr 0035f1c4 771a0bdd ntdll!ZwWaitForMultipleObjects+0x15 0035f260 75771a2c KERNELBASE!WaitForMultipleObjectsEx+0x100 0035f2a8 75774208 kernel32!WaitForMultipleObjectsExImplementation+0xe0 0035f2c4 757980a4 kernel32!WaitForMultipleObjects+0x18 0035f330 75797f63 kernel32!WerpReportFaultInternal+0x186 0035f344 75797858 kernel32!WerpReportFault+0x70 0035f354 757977d7 kernel32!BasepReportFault+0x20 0035f3e0 77ec74df kernel32!UnhandledExceptionFilter+0x1af 0035f3e8 77ec73bc ntdll!__RtlUserThreadStart+0x62 0035f3fc 77ec7261 ntdll!_EH4_CallFilterFunc+0x12 0035f424 77eab459 ntdll!_except_handler4+0x8e 0035f448 77eab42b ntdll!ExecuteHandler2+0x26 0035f46c 77eab3ce ntdll!ExecuteHandler+0x24 0035f4f8 77e60133 ntdll!RtlDispatchException+0x127 0035f4f8 73eb2200 ntdll!KiUserExceptionDispatcher+0xf WARNING: Frame IP not in any known module. Following frames may be wrong. 0035f844 76e462fa <Unloaded_fpb.tmp>+0×12200 0035f870 76e46d3a USER32!InternalCallWinProc+0×23 0035f8e8 76e4965e USER32!UserCallWinProcCheckWow+0×109 0035f92c 76e496c5 USER32!SendMessageWorker+0×581 0035f950 7269c05c USER32!SendMessageW+0×7f 0035f9ec 7270be62 comctl32!CCSendNotify+0xc19 0035fa28 75f6f52a comctl32!SendNotify+0×36 0035fa4c 75f61d66 SHELL32!SetAppStartingCursor+0×6d 0035fa64 75f61ee2 SHELL32!CShellExecute::ExecuteNormal+0×16 0035fa78 75f61e70 SHELL32!ShellExecuteNormal+0×33 0035fa90 75f53cd0 SHELL32!ShellExecuteExW+0×62 0035fae4 003e2211 SHELL32!ShellExecuteW+0×77 0035fbc4 77e838be InstallFlashPlayer+0×2211 0035fcb4 77e83492 ntdll!RtlpFreeHeap+0xbb1 0035fcd4 757714dd ntdll!RtlFreeHeap+0×142 0035fce8 003f0324 kernel32!HeapFree+0×14 0035fd80 003f0241 InstallFlashPlayer+0×10324 0035fe10 7577339a InstallFlashPlayer+0×10241 0035fe1c 77e89ef2 kernel32!BaseThreadInitThunk+0xe 0035fe5c 77e89ec5 ntdll!__RtlUserThreadStart+0×70 0035fe74 00000000 ntdll!_RtlUserThreadStart+0×1b

1 Id: bc8.6b0 Suspend: 2 Teb: 7efda000 Unfrozen ChildEBP RetAddr 03e1f9e0 77ea2f51 ntdll!ZwWaitForMultipleObjects+0x15 03e1fb74 7577339a ntdll!TppWaiterpThread+0x33d 03e1fb80 77e89ef2 kernel32!BaseThreadInitThunk+0xe 03e1fbc0 77e89ec5 ntdll!__RtlUserThreadStart+0x70 03e1fbd8 00000000 ntdll!_RtlUserThreadStart+0x1b

2 Id: bc8.8dc Suspend: 2 Teb: 7efd7000 Unfrozen ChildEBP RetAddr 03f5fd50 77ea3352 ntdll!NtWaitForWorkViaWorkerFactory+0x12 03f5feb0 7577339a ntdll!TppWorkerThread+0x216 03f5febc 77e89ef2 kernel32!BaseThreadInitThunk+0xe 03f5fefc 77e89ec5 ntdll!__RtlUserThreadStart+0x70 03f5ff14 00000000 ntdll!_RtlUserThreadStart+0x1b

3 Id: bc8.944 Suspend: 2 Teb: 7efaf000 Unfrozen ChildEBP RetAddr 0416f8b4 77ea3352 ntdll!NtWaitForWorkViaWorkerFactory+0x12 0416fa14 7577339a ntdll!TppWorkerThread+0x216 0416fa20 77e89ef2 kernel32!BaseThreadInitThunk+0xe 0416fa60 77e89ec5 ntdll!__RtlUserThreadStart+0x70 0416fa78 00000000 ntdll!_RtlUserThreadStart+0x1b

Exception thread shows fpb.tmp module as unloaded:

0:000> lmv m fpb.tmp start end module name

Unloaded modules: 00cb0000 00d5a000 fpb.tmp Timestamp: Fri Jun 01 02:56:00 2012 (4FC82130) Checksum: 000B0CD5 ImageSize: 000AA000 73ea0000 73f15000 fpb.tmp Timestamp: Fri Jun 01 02:49:25 2012 (4FC81FA5) Checksum: 0007A7CE ImageSize: 00075000

We change the exception thread context to get registers at the time of the exception:

0:000> kv ChildEBP RetAddr Args to Child 0035f1c4 771a0bdd 00000002 0035f214 00000001 ntdll!ZwWaitForMultipleObjects+0x15 0035f260 75771a2c 0035f214 0035f288 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100 0035f2a8 75774208 00000002 7efde000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0 0035f2c4 757980a4 00000002 0035f2f8 00000000 kernel32!WaitForMultipleObjects+0x18 0035f330 75797f63 0035f410 00000001 00000001 kernel32!WerpReportFaultInternal+0x186 0035f344 75797858 0035f410 00000001 0035f3e0 kernel32!WerpReportFault+0x70 0035f354 757977d7 0035f410 00000001 658587c7 kernel32!BasepReportFault+0x20 0035f3e0 77ec74df 00000000 77ec73bc 00000000 kernel32!UnhandledExceptionFilter+0x1af 0035f3e8 77ec73bc 00000000 0035fe5c 77e7c530 ntdll!__RtlUserThreadStart+0x62 0035f3fc 77ec7261 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 0035f424 77eab459 fffffffe 0035fe4c 0035f560 ntdll!_except_handler4+0x8e 0035f448 77eab42b 0035f510 0035fe4c 0035f560 ntdll!ExecuteHandler2+0x26 0035f46c 77eab3ce 0035f510 0035fe4c 0035f560 ntdll!ExecuteHandler+0x24 0035f4f8 77e60133 0135f510 0035f560 0035f510 ntdll!RtlDispatchException+0x127 0035f4f8 73eb2200 0135f510 0035f560 0035f510 ntdll!KiUserExceptionDispatcher+0xf (CONTEXT @ 0035f560) WARNING: Frame IP not in any known module. Following frames may be wrong. 0035f844 76e462fa 000201ce 0000004e 00000000 <Unloaded_fpb.tmp>+0×12200 0035f870 76e46d3a 73eb2200 000201ce 0000004e USER32!InternalCallWinProc+0×23 0035f8e8 76e4965e 00000000 73eb2200 000201ce USER32!UserCallWinProcCheckWow+0×109 0035f92c 76e496c5 013907f0 00000000 73eb2200 USER32!SendMessageWorker+0×581 0035f950 7269c05c 000201ce 0000004e 00000000 USER32!SendMessageW+0×7f 0035f9ec 7270be62 0035fa00 fffffff7 00000000 comctl32!CCSendNotify+0xc19 0035fa28 75f6f52a 000201ce 00000000 fffffff7 comctl32!SendNotify+0×36 0035fa4c 75f61d66 000201ce 00000001 00001500 SHELL32!SetAppStartingCursor+0×6d 0035fa64 75f61ee2 0035faa4 00001500 0035faa4 SHELL32!CShellExecute::ExecuteNormal+0×16 0035fa78 75f61e70 0035faa4 00001500 00000200 SHELL32!ShellExecuteNormal+0×33 0035fa90 75f53cd0 0035faa4 003fb654 003fa554 SHELL32!ShellExecuteExW+0×62 0035fae4 003e2211 000201ce 003fa554 0035fb14 SHELL32!ShellExecuteW+0×77 0035fbc4 77e838be 00da0138 77e8389a 77c467ad InstallFlashPlayer+0×2211 0035fcb4 77e83492 00000000 00da2320 00da2320 ntdll!RtlpFreeHeap+0xbb1 0035fcd4 757714dd 00da0000 00000000 00da2320 ntdll!RtlFreeHeap+0×142 0035fce8 003f0324 00da0000 00000000 003f0343 kernel32!HeapFree+0×14 0035fd80 003f0241 003e0000 00000000 010d3135 InstallFlashPlayer+0×10324 0035fe10 7577339a 7efde000 0035fe5c 77e89ef2 InstallFlashPlayer+0×10241 0035fe1c 77e89ef2 7efde000 77c46545 00000000 kernel32!BaseThreadInitThunk+0xe 0035fe5c 77e89ec5 003f02ac 7efde000 ffffffff ntdll!__RtlUserThreadStart+0×70 0035fe74 00000000 003f02ac 7efde000 00000000 ntdll!_RtlUserThreadStart+0×1b

0:000> .cxr 0035f560 eax=73eb2200 ebx=00000000 ecx=01080d68 edx=00000000 esi=73eb2200 edi=00000000 eip=73eb2200 esp=0035f848 ebp=0035f870 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 <Unloaded_fpb.tmp>+0×12200: 73eb2200 ?? ???

Then we double check that a window procedure was indeed called from that module range:

0:000> kv *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 0035f844 76e462fa 000201ce 0000004e 00000000 <Unloaded_fpb.tmp>+0×12200 0035f870 76e46d3a 73eb2200 000201ce 0000004e USER32!InternalCallWinProc+0×23 0035f8e8 76e4965e 00000000 73eb2200 000201ce USER32!UserCallWinProcCheckWow+0×109 0035f92c 76e496c5 013907f0 00000000 73eb2200 USER32!SendMessageWorker+0×581 0035f950 7269c05c 000201ce 0000004e 00000000 USER32!SendMessageW+0×7f 0035f9ec 7270be62 0035fa00 fffffff7 00000000 comctl32!CCSendNotify+0xc19 0035fa28 75f6f52a 000201ce 00000000 fffffff7 comctl32!SendNotify+0×36 0035fa4c 75f61d66 000201ce 00000001 00001500 SHELL32!SetAppStartingCursor+0×6d 0035fa64 75f61ee2 0035faa4 00001500 0035faa4 SHELL32!CShellExecute::ExecuteNormal+0×16 0035fa78 75f61e70 0035faa4 00001500 00000200 SHELL32!ShellExecuteNormal+0×33 0035fa90 75f53cd0 0035faa4 003fb654 003fa554 SHELL32!ShellExecuteExW+0×62 0035fae4 003e2211 000201ce 003fa554 0035fb14 SHELL32!ShellExecuteW+0×77 0035fbc4 77e838be 00da0138 77e8389a 77c467ad InstallFlashPlayer+0×2211 0035fcb4 77e83492 00000000 00da2320 00da2320 ntdll!RtlpFreeHeap+0xbb1 00da15a0 00000000 00da1780 02971450 003e1000 ntdll!RtlFreeHeap+0×142

0:000> ub 76e462fa USER32!InternalCallWinProc+0×6: 76e462dd 68cdabbadc push 0DCBAABCDh 76e462e2 56 push esi 76e462e3 ff7518 push dword ptr [ebp+18h] 76e462e6 ff7514 push dword ptr [ebp+14h] 76e462e9 ff7510 push dword ptr [ebp+10h] 76e462ec ff750c push dword ptr [ebp+0Ch] 76e462ef 64800dca0f000001 or byte ptr fs:[0FCAh],1 76e462f7 ff5508 call dword ptr [ebp+8]

We now get a memory value pointed to by EBP+8 address:

0:000> r Last set context: eax=73eb2200 ebx=00000000 ecx=01080d68 edx=00000000 esi=73eb2200 edi=00000000 eip=73eb2200 esp=0035f848 ebp=0035f870 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 <Unloaded_fpb.tmp>+0×12200: 73eb2200 ?? ???

0:000> dp 0035f870+8 l1 0035f878 73eb2200

0:000> dd 73eb2200 73eb2200 ???????? ???????? ???????? ???????? 73eb2210 ???????? ???????? ???????? ???????? 73eb2220 ???????? ???????? ???????? ???????? 73eb2230 ???????? ???????? ???????? ???????? 73eb2240 ???????? ???????? ???????? ???????? 73eb2250 ???????? ???????? ???????? ???????? 73eb2260 ???????? ???????? ???????? ???????? 73eb2270 ???????? ???????? ???????? ????????

The value is indeed belongs to unloaded fpb.tmp module address range:

0:000> ln 73eb2200 (73eb2200) <Unloaded_fpb.tmp>+0×12200

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

Posted in Crash Dump Analysis, Crash Dump Patterns, Debugging | 2 Comments »

FBI (Debugging Slang, Part 35)

June 27th, 2012

FBI - Fighting Bugs Inside.

Examples: I’m doing an FBI work now!

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

Posted in Debugging Slang, Fun with Crash Dumps, Fun with Debugging, Fun with Intelligence Analysis, Fun with Malware, New Acronyms | No Comments »

poo (Debugging Slang, Part 34)

June 25th, 2012

poo - a function that follows foo and bar with a purpose to trigger a crash event, a breakpoint or save memory state.

Examples: void main() { foo(); } void foo() { poo(); } void poo() { asm int 3; }

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

Posted in Debugging Slang, Fun with Crash Dumps, Fun with Debugging | No Comments »

STaMPs (Debugging Slang, Part 33)

June 25th, 2012

STaMPs - Software Trace and Memory Patterns. Stack Trace and Memory Patterns.

Examples: Got a few visible stamps on this trace. And more stamps on that crash dump.

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

Posted in Debugging Slang, Fun with Crash Dumps, Fun with Debugging, Fun with Software Traces, New Acronyms | No Comments »

Webinar: Introduction to Systemic Software Diagnostics

June 24th, 2012

This is a second Webinar from Memory Dump Analysis Services on software diagnostics. The first one is about pattern recognition. During this Webinar you will learn how to apply systems theory and systems thinking for effective and efficient abnormal software behavior diagnostics: the foundation of software troubleshooting and debugging. The seminar summarizes 6 years of research done by Software Diagnostics Institute started with a short blog post Dumps and Systems Theory.

Introduction to Systemic Software Diagnostics Logo

Title: Introduction to Systemic Software Diagnostics: Systems Thinking in Memory Dump and Software Trace Analysis
Date: 3rd of September, 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/377382766

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

Posted in Announcements, Memory Dump Analysis Services, Software Diagnostics, Software Diagnostics Institute, Software Diagnostics Patterns, Software Engineering, Software Technical Support, Systems Thinking, Training and Seminars, Unified Software Diagnostics, Webinars | No Comments »

Webinar on Victimware: The Missing Part of the Equation

June 24th, 2012

Memory Dump Analysis Services organizes a free webinar on a unified malware and victimware analysis by using behavioral and structural patterns including a live memory dump analysis example.

Victimware Analysis Webinar Logo

Date: 2nd of July, 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/332458406

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

Posted in Announcements, Malware Analysis, Memory Dump Analysis Services, Security, Software Behavior Patterns, Victimware, Webinars | No Comments »

Trace Analysis Patterns (Part 51)

June 23rd, 2012

Counter Value pattern covers performance monitoring and its logs. A counter value is some variable in memory, for example, a module variable, that is updated periodically to reflect some aspect of state or it can be calculated from different such variables and presented in trace messages. Such messages can also be organized in a similar format as ETW based traces we usually consider as examples for our trace patterns:

Source PID TID Function Value ================================================= […] System 0 0 Committed Memory 12,002,234,654 Process 844 0 Private Bytes 345,206,456 System 0 0 Committed Memory 12,002,236,654 Process 844 0 Working Set 122,160,068 […]

Therefore, all other trace patterns such as adjoint thread (can be visualized via different colors on a graph), focus of tracing, characteristic message block (for graphs), activity region, significant event, and others can be applicable here. There are also some specific patterns such as global monotonicity and constant value that we discuss with examples in subsequent parts.

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

Posted in Performance Monitoring, Software Diagnostics, Software Trace Analysis, Software Trace Reading, Software Trace Visualization, Trace Analysis Patterns | No Comments »

Individual and Enterprise Software Diagnostics Certifications

June 18th, 2012

Memory Dump Analysis Services will be administering certifications developed by Software Diagnostics Institute for memory dump and software trace analysis:

Software Diagnostics Maturity Enterprise Certification
Memory Dump Analysis Certification is available this September

Debugging TV Frames episode 0×10 contains some background information.

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

Posted in Announcements, Certification, Core Dump Analysis, Crash Dump Analysis, Crash Dump Patterns, Debugging, Software Diagnostics, Software Diagnostics Institute, Software Diagnostics Patterns, Software Engineering, Software Technical Support, Software Trace Analysis, Trace Analysis Patterns | No Comments »

Software Diagnostics Institute

June 12th, 2012

DumpAnalysis.org portal has been reorganized to Software Diagnostics Institute to reflect the nature of its research activities. More updates later on.

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

Posted in Announcements, Core Dump Analysis, Crash Dump Analysis, Crash Dump Patterns, Debugging, Software Behavior Patterns, Software Diagnostics, Software Diagnostics Institute, Software Diagnostics Patterns, Software Engineering, Software Trace Analysis, Trace Analysis Patterns | No Comments »

A NoSQL Problem (Debugging Slang, Part 32)

June 10th, 2012

A NoSQL Problem - when nothing appears on a refresh.

Examples: I got a NoSQL problem when I signed in to that social website.

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

Posted in Debugging Slang, Fun with Debugging, SQL Debugging | No Comments »

Patterns of Software Diagnostics (Part 1)

June 9th, 2012

While preparing a seminar on Software Diagnostics I made a lot of notes and realized that a system of patterns, corresponding vocabulary and pattern language are needed for this discipline. Here patterns are supposed to be broad in nature and be different from patterns for specific artifacts such as memory dumps and software traces. So the first pattern addresses a diagnostic encounter with a First Fault in comparison to subsequent faults where the problem becomes noticeable and diagnostic resources are allocated. Such faults should not be dismissed. Dan Skwire is a passionate advocate of first fault software problem solving and wrote a book:

First Fault Software Problem Solving: A Guide for Engineers, Managers and Users

The following paper proposes distributed control flow reconstruction for first fault diagnosis:

TraceBack: First Fault Diagnosis by Reconstruction of Distributed Control Flow

Memory Dump Analysis Services uses patterns of abnormal software behavior for its first fault diagnostics that doesn’t require any special instrumentation:

Join Debugging Diagnostics Revolution!

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

Posted in First Fault Problem Solving, Software Behavior Patterns, Software Diagnostics, Software Diagnostics Patterns, Software Technical Support, Unified Software Diagnostics | No Comments »

Crash Dump Analysis Patterns (Part 177)

June 9th, 2012

Stack Trace Change is an important pattern for differential memory dump analysis, for example, when memory dumps were generated before and after a problem such as a CPU spike or hang. In the example below we have a normal expected thread stack trace from a memory dump saved before an application was reported unresponsive and another different thread stack trace after:

3 Id: 24b8.24e4 Suspend: 0 Teb: 7efa1000 Unfrozen ChildEBP RetAddr 037dfadc 75210bdd ntdll!ZwWaitForMultipleObjects+0x15 037dfb78 75791a2c KERNELBASE!WaitForMultipleObjectsEx+0x100 037dfbc0 7511086a kernel32!WaitForMultipleObjectsExImplementation+0xe0 037dfc14 00d17c1d user32!RealMsgWaitForMultipleObjectsEx+0x14d 037dfc3c 00ce161d ApplicationA!MsgWaitForMultipleObjects+0x2d 037dfc60 00cdc757 ApplicationA!WaitForSignal+0x1d 037dfc80 00cdaaf6 ApplicationA!WorkLoop+0x57 037dfca4 7579339a ApplicationA!ThreadStart+0x26 037dfcb0 77699ef2 kernel32!BaseThreadInitThunk+0xe 037dfcf0 77699ec5 ntdll!__RtlUserThreadStart+0x70 037dfd08 00000000 ntdll!_RtlUserThreadStart+0x1b

3 Id: 24b8.24e4 Suspend: 0 Teb: 7efa1000 Unfrozen ChildEBP RetAddr 037df38c 752131bb ntdll!ZwDelayExecution+0x15 037df3f4 75213a8b KERNELBASE!SleepEx+0x65 037df404 00d1670b KERNELBASE!Sleep+0xf 037df40c 00d350ef ApplicationA!Sleep+0xb 037df430 6a868aab ApplicationA!PutData+0xbf 037df444 6a8662ec ModuleA!OutputData+0x1b 037df464 00d351de ModuleA!ProcessData+0x16c 037df4a4 00ca8cb4 ApplicationA!SendData+0xbe [...]

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

Posted in Crash Dump Analysis, Crash Dump Patterns, Debugging | No Comments »

Pages

Recent Comments

Categories

Archives

ARM64

Automated Analysis

Blogroll

Debugging Channels

Forensics

Hardware

Linux

Mac OS X

Magazines and Newspapers

Malware Analysis

Medical Diagnostics

Narratology

Related Links

Reversing

Scripting Languages

Source Code

Tracing Tools

Meta