Archive for March, 2011

Crash Dump Analysis Patterns (Part 134a)

Monday, March 28th, 2011

Data Correlation is a general pattern where values found in different parts of a memory dump correlate between each other according to some rules, for example, in some proportion. Here we show a variant for function parameters.

A process user memory dump showed a C++ exception:

0:000> kL
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr 
0012e950 78158e89 kernel32!RaiseException+0x53
0012e988 7830770c msvcr80!_CxxThrowException+0×46
0012e99c 783095bc mfc80u!AfxThrowMemoryException+0×19
0012e9b4 02afa8ca mfc80u!operator new+0×27

0012e9c8 02b0992f ModuleA!std::_Allocate<…>+0×1a
0012e9e0 02b09e7c ModuleA!std::vector<double,std::allocator<double> >::vector<double,std::allocator<double> >+0×3f
[…]

We suspected an out-of-memory condition and looked for function parameters:

0:000> kv 5
ChildEBP RetAddr  Args to Child             
0012e950 78158e89 e06d7363 00000001 00000003 kernel32!RaiseException+0x53
0012e988 7830770c 0012e998 783b0110 783c8d68 msvcr80!_CxxThrowException+0x46
0012e99c 783095bc 0000a7c0 0012ea40 000014f8 mfc80u!AfxThrowMemoryException+0x19
0012e9b4 02afa8ca 0000a7c0 089321b0 089321f0 mfc80u!operator new+0×27 (FPO: [Uses EBP] [1,0,0])
0012e9c8 02b0992f 000014f8 00000000 00000008 ModuleA!std::_Allocate<…>+0×1a (FPO: [2,3,0])

Because of FPO optimization we originally thought that stack arguments would be invalid. However, bearing in mind the function prototype and semantics of operator new and std::vector double element type we immediately see the correlation between 0xa7c0 and 0×14f8 which are proportional to sizeof(double) == 8:

0:000> ? 0000a7c0/000014f8
Evaluate expression: 8 = 00000000`00000008

We therefore conclude without looking at disassembly that memory allocation size was 42944 bytes:

0:000> .formats 0000a7c0
Evaluate expression:
  Hex:     00000000`0000a7c0
  Decimal: 42944
  Octal:   0000000000000000123700
  Binary:  00000000 00000000 00000000 00000000 00000000 00000000 10100111 11000000
  Chars:   ……..
  Time:    Thu Jan 01 11:55:44 1970
  Float:   low 6.01774e-041 high 0
  Double:  2.12172e-319

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

5 Years of DumpAnalysis.org!

Saturday, March 26th, 2011

I’m speechless for this occasion, look with awe at what has been done, and can only show a slide from the yesterday’s presentation Introduction to Pattern-Driven Software Problem Solving:

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

Presentation from Webinar: Introduction to Pattern-Driven Software Problem Solving

Saturday, March 26th, 2011

The presentation materials from the webinar (25th of March, 2011) are available for download:

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

Thanks to everyone who registered and attended!

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

DBI: Debugging Bureau of Investigations

Thursday, March 24th, 2011

Memory Dump Analysis Services opens Debugging Bureau to complement crash and hang memory dump analysis audit:

http://www.dumpanalysis.com/debugging-bureau

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

Icons for Memory Dump Analysis Patterns (Part 94)

Wednesday, March 23rd, 2011

Today we introduce an icon for Stack Overflow (software implementation) pattern:

B/W

Color

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

Advanced Software Debugging Reference

Wednesday, March 23rd, 2011

While working on Pattern-Driven Software Problem Solving Webinars I needed a reference page that lists all Memory Dump Analysis Anthology volumes:

Advanced Software Debugging Reference

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

Resuming Literate Scientist Blog

Sunday, March 20th, 2011

Due to my Mod N Reading System I had to suspend this blog because N became large (about 100 or more books) and there wasn’t enough read material to review. Now I accumulated some books fully read from cover to cover and many others read to a sufficient number of pages to make an opinion and suggest recommendations. So I’m resuming this blog and plan to write about the next book tomorrow. It will be a history of social sciences. I plan to introduce a new book every day or so. I also made an alteration to Mod N reading to include thematic encyclopedias. Stay tuned.

- Dmitry Vostokov @ LiterateScientist.com -

Crash Dump Analysis Patterns (Part 133)

Sunday, March 20th, 2011

Sometimes we see Truncated Stack Trace with missing stack frames. For example, in one incident, after enabling user mode stack trace database for a memory leaking application we got these entries from the growing heap segment (other segments had non-truncated saved stack traces):

0bdc1350: 40010 . 40010 [101] - busy (3fff8) Internal

    7702fbd2: ntdll!RtlAllocateHeap+0x0000021d
    77005eef: ntdll!RtlpAllocateUserBlock+0x000000a2
    77026a65: ntdll!RtlpLowFragHeapAllocFromContext+0x00000785
    7702661f: ntdll!RtlAllocateHeap+0x0000017c

0be01360: 40010 . 40010 [101] - busy (3fff8) Internal

    7702fbd2: ntdll!RtlAllocateHeap+0x0000021d
    77005eef: ntdll!RtlpAllocateUserBlock+0x000000a2
    77026a65: ntdll!RtlpLowFragHeapAllocFromContext+0x00000785
    7702661f: ntdll!RtlAllocateHeap+0x0000017c

0be41370: 40010 . 40010 [101] - busy (3fff8) Internal

    7702fbd2: ntdll!RtlAllocateHeap+0x0000021d
    77005eef: ntdll!RtlpAllocateUserBlock+0x000000a2
    77026a65: ntdll!RtlpLowFragHeapAllocFromContext+0x00000785
    7702661f: ntdll!RtlAllocateHeap+0x0000017c

Truncated traces are different from incorrect stack traces because their surviving part is correct. How can we find the rest of such stack traces? Here we can suggest to look at other heap segments and see allocations of the same size. If a truncated trace comes from a stack trace collection we can compare it with a non-truncated thread stack from another process instance having the same thread position. Other suggestions are welcome too, especially, for the mysterious memory leak shown above.

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

Analysis Compass

Friday, March 18th, 2011

The forthcoming Software Behavior Analysis Patterns and Checklists: Corporate Reference Poster Edition for Windows Crash and Hang Memory Dump and Software Trace Analysis (ISBN: 978-1908043030) will feature Analysis Compass based on the reversal of an extended version of pattern-to-command table published in the printed version of Debugged! MZ/PE March, 2009 issue. Here’s a sneak preview screenshot of this feature:

The notation F”Function” means searching for frames having the given Function name in stack traces from Stack Trace Collection. S”String” means searching for String in the output of WinDbg commands, for example, !process 0 ff.

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

Flags and Handles are Everywhere!

Friday, March 18th, 2011

Frequently caught myself recognizing bit values like 100084 when I’m looking at car plate numbers. Sometimes I see a number and wonder whether it is a valid window handle.

Do you also have similar perceptions? Please let me know if you have different memceptions :-)

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

Bugtation No.140

Thursday, March 17th, 2011

“If you want to be thought a” debugger “, always” talk about bugs.

Logan Pearsall Smith

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

Bugtation No.139

Monday, March 14th, 2011

“… he who has not been in” support “does not know what” debugging “is.”

Attributed to Leo Tolstoy, by Adam Ulam, The Bolsheviks

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

Crash Dump Analysis Patterns (Part 132)

Saturday, March 12th, 2011

Sometimes simple comparison of crash signatures is not enough to find similar support incidents. We then traverse stack trace frames to find Least Common Frame matching similar stack traces in a database. For example, consider this signature:

0:026> r
eax=011349ec ebx=01136738 ecx=79f943e1 edx=00000000 esi=011349ec edi=0888f3b8
eip=00dfbef8 esp=0888f348 ebp=0888f3c8 iopl=0  nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000  efl=00000246
00dfbef8 3902  cmp     dword ptr [edx],eax  ds:0023:00000000=????????

0:026> k 100
ChildEBP RetAddr 
WARNING: Frame IP not in any known module. Following frames may be wrong.
0888f3c8 792a842f 0xdfbef8
0888f3e4 792a839b mscorlib_ni+0x1e842f
0888f3fc 79e71b4c mscorlib_ni+0x1e839b
0888f40c 79e821b9 mscorwks!CallDescrWorker+0×33
0888f48c 79e8281f mscorwks!CallDescrWorkerWithHandler+0xa3
0888f4ac 79e82860 mscorwks!DispatchCallBody+0×1e
0888f510 79e828d1 mscorwks!DispatchCallDebuggerWrapper+0×3d
0888f544 79ec50f5 mscorwks!DispatchCallNoEH+0×51
0888f5a0 79e9848f mscorwks!AddTimerCallback_Worker+0×66
0888f5b4 79e9842b mscorwks!Thread::DoADCallBack+0×32a
0888f648 79e98351 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3
0888f684 79e984dd mscorwks!Thread::ShouldChangeAbortToUnload+0×30a
0888f6ac 79ec4a84 mscorwks!Thread::ShouldChangeAbortToUnload+0×33e
0888f6c4 79ec5075 mscorwks!ManagedThreadBase::ThreadPool+0×13
0888f70c 79ec50a4 mscorwks!AddTimerCallbackEx+0×83
0888f720 79ec514a mscorwks!AddTimerCallback+0×10
0888f75c 79ec4e0c mscorwks!ThreadpoolMgr::AsyncTimerCallbackCompletion+0×64
0888f7a8 79ec471e mscorwks!UnManagedPerAppDomainTPCount::DispatchWorkItem+0×9a
0888f7bc 79ec4892 mscorwks!ThreadpoolMgr::ExecuteWorkRequest+0xaf
0888f814 79f75715 mscorwks!ThreadpoolMgr::WorkerThreadStart+0×20b
0888ffb4 7c80b729 mscorwks!Thread::intermediateThreadProc+0×49
0888ffec 00000000 kernel32!BaseThreadStart+0×37

Most likely we won’t find any similar stack trace when searching for 0xdfbef8. The search for mscorlib_ni+0×1e842f brings several results but they are not crashes but hangs with the frame being in the middle of call stack. The same is for mscorlib_ni+0×1e839b. So we finally try searching for CallDescrWorker+0×33 but with a limit to results having the same application module name. And indeed we find the similar software incident with the same stack trace after our least common frame:

0:004> r
eax=00000024 ebx=03e6f738 ecx=738129d8 edx=00495ef0 esi=01a87c4c edi=019c5f1c
eip=00a92037 esp=03e6f6cc ebp=03e6f6e8 iopl=0 nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b  efl=00010206
00a92037 ??              ???

0:004> k 100
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr 
WARNING: Frame IP not in any known module. Following frames may be wrong.
03e6f6c8 737d6bb5 0xa92037
03e6f6e8 737a509f mscorlib_ni+0x216bb5
03e6f6f8 737a834c mscorlib_ni+0x1e509f
03e6f70c 74171b6c mscorlib_ni+0x1e834c
03e6f71c 74182209 mscorwks!CallDescrWorker+0×33
03e6f79c 7418286f mscorwks!CallDescrWorkerWithHandler+0xa3
03e6f7bc 741828b0 mscorwks!DispatchCallBody+0×1e
03e6f820 74182921 mscorwks!DispatchCallDebuggerWrapper+0×3d
03e6f854 742ced79 mscorwks!DispatchCallNoEH+0×51
03e6f8b0 7419846f mscorwks!AddTimerCallback_Worker+0×66
03e6f8c4 7419840b mscorwks!Thread::DoADCallBack+0×32a
03e6f958 74198331 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3
03e6f994 741984bd mscorwks!Thread::ShouldChangeAbortToUnload+0×30a
03e6f9bc 742ce708 mscorwks!Thread::ShouldChangeAbortToUnload+0×33e
03e6f9d4 742cecf9 mscorwks!ManagedThreadBase::ThreadPool+0×13
03e6fa1c 742ced28 mscorwks!AddTimerCallbackEx+0×83
03e6fa30 742cedce mscorwks!AddTimerCallback+0×10
03e6fa6c 742cea90 mscorwks!ThreadpoolMgr::AsyncTimerCallbackCompletion+0×64
03e6fab8 742ce3a2 mscorwks!UnManagedPerAppDomainTPCount::DispatchWorkItem+0×9a
03e6facc 742ce516 mscorwks!ThreadpoolMgr::ExecuteWorkRequest+0xaf
03e6fb64 74441ec9 mscorwks!ThreadpoolMgr::WorkerThreadStart+0×20b
03e6fc84 76813677 mscorwks!Thread::intermediateThreadProc+0×49
03e6fc90 77219d72 kernel32!BaseThreadInitThunk+0xe
03e6fcd0 77219d45 ntdll!__RtlUserThreadStart+0×70
03e6fce8 00000000 ntdll!_RtlUserThreadStart+0×1b

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

Reading Notebook: 04-March-11

Thursday, March 10th, 2011

Comments in italics are mine and express my own views, thoughts and opinions

Windows Internals by M. Russinovich, D. Solomon and A. Ionescu:

HKLM\S\MountedDevices and basic disk volume partition offset (pp. 667 - 668)

General reparse points; symbolic links and mount points as their applications (p. 669)

Device object -> VPB, !vpb WinDbg command (p. 670) - here’s on my x64 W2K8 system:

0: kd> dt _DEVICE_OBJECT
ntdll!_DEVICE_OBJECT
+0x000 Type             : Int2B
+0x002 Size             : Uint2B
+0x004 ReferenceCount   : Int4B
+0x008 DriverObject     : Ptr64 _DRIVER_OBJECT
+0x010 NextDevice       : Ptr64 _DEVICE_OBJECT
+0x018 AttachedDevice   : Ptr64 _DEVICE_OBJECT
+0x020 CurrentIrp       : Ptr64 _IRP
+0x028 Timer            : Ptr64 _IO_TIMER
+0x030 Flags            : Uint4B
+0x034 Characteristics  : Uint4B
   +0×038 Vpb              : Ptr64 _VPB
+0×040 DeviceExtension  : Ptr64 Void
+0×048 DeviceType       : Uint4B
+0×04c StackSize        : Char
+0×050 Queue            : <unnamed-tag>
+0×098 AlignmentRequirement : Uint4B
+0×0a0 DeviceQueue      : _KDEVICE_QUEUE
+0×0c8 Dpc              : _KDPC
+0×108 ActiveThreadCount : Uint4B
+0×110 SecurityDescriptor : Ptr64 Void
+0×118 DeviceLock       : _KEVENT
+0×130 SectorSize       : Uint2B
+0×132 Spare1           : Uint2B
+0×138 DeviceObjectExtension : Ptr64 _DEVOBJ_EXTENSION
+0×140 Reserved         : Ptr64 Void

0: kd> dt _VPB
ntdll!_VPB
+0x000 Type             : Int2B
+0x002 Size             : Int2B
+0x004 Flags            : Uint2B
+0x006 VolumeLabelLength : Uint2B
+0x008 DeviceObject     : Ptr64 _DEVICE_OBJECT
+0x010 RealDevice       : Ptr64 _DEVICE_OBJECT
+0x018 SerialNumber     : Uint4B
+0x01c ReferenceCount   : Uint4B
+0x020 VolumeLabel      : [32] Wchar

FS -> Volume I/O (pp. 674 - 675) - we can also see driver stack from IRP I/O stack locations:

2: kd> !irp fffffa8017492b80
[...]
cmd  flg cl Device   File     Completion-Context
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                     Args: 00000000 00000000 00000000 00000000
>[  4,34]  1c e0 fffffa800dfe2060 00000000 fffff88001186f30-00000000 Success Error Cancel
\Driver\Disk  partmgr!PmReadWriteCompletion
Args: 00001000 00000000 b99a9000 00000000
[  4, 0]  1c e0 fffffa800dfe2b90 00000000 fffff88001197180-fffffa800da89e20 Success Error Cancel
\Driver\partmgr     volmgr!VmpReadWriteCompletionRoutine
Args: 148ce8c5bed 00000000 b99a9000 00000000
[  4, 0]   c e0 fffffa800da89cd0 00000000 fffff88001968150-fffffa800dfe7190 Success Error Cancel
\Driver\volmgr      volsnap!VspRefCountCompletionRoutine
Args: 00001000 00000000 148ce8c5be9 00000000
[  4, 0]   c e1 fffffa800dfe7040 00000000 fffff88001a464f4-fffff88002777a10 Success Error Cancel pending
\Driver\volsnap     Ntfs!NtfsMasterIrpSyncCompletionRoutine
Args: 00001000 00000000 b996a000 00000000
[  4, 0]   0  0 fffffa800dfed030 fffffa800da958e0 00000000-00000000
\FileSystem\Ntfs
Args: 00001000 00000000 01afc000 00000000
[…]

BitLocker architecture diagram (p.678) - parts can be seen from IRP I/O stack locations:

 kd> !irp 85e7ee00
[...]
cmd  flg cl Device   File     Completion-Context
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                  Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                  Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                  Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                  Args: 00000000 00000000 00000000 00000000
[  0, 0]   0  0 00000000 00000000 00000000-00000000   

                  Args: 00000000 00000000 00000000 00000000
>[  3,34]  10 e0 857b9030 00000000 8353724e-00000000 Success Error Cancel
\Driver\Disk     partmgr!PmReadWriteCompletion
Args: 00001000 00000000 400d6000 00000000
[  3, 0]  10  0 857b9d18 00000000 00000000-00000000
\Driver\partmgr
Args: 6bad71d7 00000000 400d6000 00000000
[  3, 0]  10 e0 8478b5f0 00000000 835487a4-857bc2f0 Success Error Cancel
\Driver\DriverA   volmgr!VmpReadWriteCompletionRoutine
Args: 00001000 00000000 400d6000 00000000
[  3, 0]   0 e0 857bc238 00000000 872c83e2-857bfb70 Success Error Cancel
\Driver\volmgr   fvevol!FvePassThroughCompletion
Args: 00001000 00000000 6bad70ba 00000000
[  3, 0]   0 e0 857bfab8 00000000 8709807a-859a2118 Success Error Cancel
\Driver\fvevol   Ntfs!NtfsMasterIrpAsyncCompletionRoutine
Args: 00001000 00000000 40097000 00000000
[  3, 0]   0  1 857e2020 8584ca40 00000000-00000000    pending
\FileSystem\Ntfs
Args: 00001000 00000000 0329e000 00000000
[…]

VMK -> FVEK: possibility for rekeying (p. 679)

Maximum protection: TPM+USB+PIN (p. 679)

Diffuser to protect from manipulations with AES-encrypted ciphertext (p. 681)

Software Trace Analysis Checklist

Thursday, March 10th, 2011

Because the number of software trace patterns is growing I’m starting another checklist in addition to memory dump analysis checklist. The goal is to help experienced engineers not to miss any important information. The checklist doesn’t prescribe any specific steps, just lists all possible points to double check when looking at a software trace. Of course, it is not complete at the moment and any suggestions are welcome. This post will be modified on the ongoing basis.

General:

• Check overall trace time delta
• Check no trace metafile message density
• Check whether a trace is a multi-part or a circular
• Check for basic facts and the story (software narrative)
• Check for any exceptions, non-false positive errors and periodic errors
• Check for significant events
• Check for discontinuities in the time domain
• Check for message current and acceleration in the frequency domain

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

10 Common Mistakes in Memory Analysis (Part 10)

Thursday, March 10th, 2011

The last common mistake in this set is when an engineer doesn’t compare stack traces or other debugger output to normal reference stack traces. For example, a 3rd party service was hanging on a W2K8 server and a user memory dump was saved for offline analysis. The following thread was identified as blocked waiting for a response:

STACK_TEXT: 
0041f1bc 75a30816 ntdll_77e50000!ZwWaitForSingleObject+0x15
0041f228 76671184 KERNELBASE!WaitForSingleObjectEx+0x98
0041f240 76671138 kernel32!WaitForSingleObjectExImplementation+0x75
0041f254 75b17be6 kernel32!WaitForSingleObject+0x12
0041f2f8 75b18040 sechost!ScSendResponseReceiveControls+0xea
0041f3ac 75b18662 sechost!ScDispatcherLoop+0xc2
0041f3ec 01271bb4 sechost!StartServiceCtrlDispatcherW+0xb0
0041fa7c 01271dd6 ServiceA!WinMain+0×254
0041fb0c 76673677 ServiceA!__tmainCRTStartup+0×160
0041fb18 77e89d42 kernel32!BaseThreadInitThunk+0xe
0041fb58 77e89d15 ntdll_77e50000!__RtlUserThreadStart+0×70
0041fb70 00000000 ntdll_77e50000!_RtlUserThreadStart+0×1b

Unfortunately, this thread wasn’t recognized as a normal main service thread. Typical Internet search for ScSendResponseReceiveControls function points to a sample analysis log where we can find such thread stacks in the variety of other standard services:

THREAD fffffa8005362060  Cid 0a1c.0b68  Teb: 000007fffffde000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
    fffffa8004dc0a60  SynchronizationEvent
Not impersonating
DeviceMap                 fffff8a000008c10
Owning Process            fffffa800540e060       Image:         svchost.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      37051          Ticks: 3239 (0:00:00:50.528)
Context Switch Count      13            
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address svchost!wmainCRTStartup (0x00000000ffa9246c)
Stack Init fffff88005abbdb0 Current fffff88005abb900
Base fffff88005abc000 Limit fffff88005ab6000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           Call Site
fffff880`05abb940 fffff800`01a93992 nt!KiSwapContext+0x7a
fffff880`05abba80 fffff800`01a95cff nt!KiCommitThreadWait+0x1d2
fffff880`05abbb10 fffff800`01d871d2 nt!KeWaitForSingleObject+0x19f
fffff880`05abbbb0 fffff800`01a8b993 nt!NtWaitForSingleObject+0xb2
fffff880`05abbc20 00000000`7781fefa nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`05abbc20)
00000000`001ffab8 000007fe`fda910ac ntdll!NtWaitForSingleObject+0xa
00000000`001ffac0 000007fe`ff4eaffb KERNELBASE!WaitForSingleObjectEx+0x79
00000000`001ffb60 000007fe`ff4e9d61 sechost!ScSendResponseReceiveControls+0×13b
00000000`001ffc50 000007fe`ff4e9c16 sechost!ScDispatcherLoop+0×121
00000000`001ffd60 00000000`ffa91d3a sechost!StartServiceCtrlDispatcherW+0×14e
00000000`001ffdb0 00000000`ffa9257a svchost!wmain+0×110
00000000`001ffde0 00000000`776cf56d svchost!ScCreateWellKnownSids+0×2fd
00000000`001ffe20 00000000`77803281 kernel32!BaseThreadInitThunk+0xd
00000000`001ffe50 00000000`00000000 ntdll!RtlUserThreadStart+0×1d

Also, studying OS architecture and deliberate practice in memory dump analysis helps in recognition of problem and normal structural and behavioral patterns.

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

Memiosphere

Wednesday, March 9th, 2011

Memiosphere is the sphere of operating memory processes where memory signs (studied by memiotics) are created, manipulated and destroyed. This new word was inspired by the similar notion of semiosphere. We can also metaphorically analyze and remember it as mem(ory) + I/O + sphere.

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

Symbols of Memorianity (Part 1)

Wednesday, March 9th, 2011

The Church of Memory Analysis acquires its first symbol as a cross with 4 pointers and a background natural memory visualization image extracted from one of computer memory dumps:

Dmitry Vostokov
Memoriarch

- Dmitry Vostokov @ Memory Religion Portal -

Notes on Memoidealism (1.12)

Wednesday, March 9th, 2011

Similar to Buddhism view of a person as a transient assemblage of physical and psychical elements Memorianity considers a person as an assemblage of memories always in flux. To be saved correctly also means working with memories to overcome their original defects and reorder chains of memory perspectives. This is similar to karmic laws and past actions that determine the nature of rebirth. See also on Morality and Memorianity.

Why it is so difficult to restore everything that was saved? Here André-Marie Ampère’s notion of dynamic resistance when we try to penetrate matter is similar to memuonic resistance when we try to penetrate Memory.

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

Forthcoming Webinar: Introduction to Pattern-Driven Software Problem Solving

Monday, March 7th, 2011

Introduction to Pattern-Driven Software Problem Solving Logo

The first Webinar to start an in-depth discussion of pattern-driven software troubleshooting, debugging and maintenance:

Date: 25th of March 2011
Time: 18:30 (GMT) 14:30 (EST) 11:30 (PST)
Duration: 60 minutes

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

Topics include:

  • A Short History of DumpAnalysis.org
  • Memory Dump Analysis Patterns
  • Troubleshooting and Debugging Tools (Debugware) Patterns
  • Software Trace Analysis Patterns
  • From Software Defects to Software Behavior
  • Workaround Patterns
  • Structural Memory Patterns
  • Memory Analysis Domain Pattern Hierarchy
  • New Directions

Prerequisites: experience in software troubleshooting and/or debugging.

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