Software Diagnostics Library

As always, if I’m asked to do something, I don’t stop there and apply all my accumulated knowledge to go beyond. Here is an example: after designing ₂CARE² trademark I imagined an organic creature that catches bugs:

If you compare it with a trademark you would recognize A, R and E as Phenyl, Methyl, and Ethyl groups.

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

Having done in the past with user space raw stack data analysis for 32-bit complete memory dumps I found today the need to look at kernel raw stack data from all threads and created this fast script:

!for_each_thread "!thread @#Thread; r? $t1 = ((nt!_KTHREAD *) @#Thread )->StackLimit; r? $t2 = ((nt!_KTHREAD *) @#Thread )->InitialStack; dps @$t1 @$t2"

It can be run for kernel and complete memory dumps from both x86 and x64 systems. If you need to have correct symbolic mapping for user space in kernel space data you need to modify it a bit and it will be slower to run.

!for_each_thread "!thread @#Thread ff; .thread /r /p @#Thread; r? $t1 = ((nt!_KTHREAD *) @#Thread )->StackLimit; r? $t2 = ((nt!_KTHREAD *) @#Thread )->InitialStack; dps @$t1 @$t2"

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

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

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

3 bugtations in a column:

Every debugger I know has trouble debugging.
Talent is helpful in debugging, but guts are absolutely necessary.
With failure comes a dump.

Joseph Heller

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

According to Google Analytics the number of visits / year increased by 4% since 2010 with almost 160,000 unique visitors (2% increase) from 180 countries and 34% of them are coming back. 2,725 visits were via 12 mobile operating systems (106% increase). Here are the top 100 network locations out of 28,932:

Top 25 visiting countries:

More than 8,000 portal and blog pages were viewed a total of more than 392,000 times with top 100 content pages:

More than 70,000 Google search keywords pointed to the portal and this blog with 100 most frequent (some are in Russian):

Special thanks to more  1,000 web sites that mention the portal and this blog with the first top 100:

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

In addition to stack trace collections for threads (unmanaged, managed and predicate) we introduce an additional pattern for I/O requests. Such requests are implemented via the so called I/O request packets (IRP) that “travel” from a device driver to a device driver similar to a C++ class method to another C++ class method (where a device object address is similar to a C++ object instance address). An IRP stack is used to keep a track of the current driver which is processing an IRP that is reused between device drivers. Its is basically an array of structures describing how a particular driver function was called with appropriate parameters similar to a call frame on an execution thread stack. Long time ago I created an UML diagram depicting the flow of an IRP through the driver (device) stack (diagram #3). An I/O stack location pointer is decremented (from the bottom to the top) like a thread stack pointer (ESP or RSP). We can list active and completed I/O requests with their stack traces using !irpfind -v WinDbg command:

1: kd> !irpfind -v

Scanning large pool allocation table for Tag: Irp? (832c7000 : 833c7000)

Irp    [ Thread ] irpStack: (Mj,Mn)   DevObj  [Driver]         MDL Process
8883dc18: Irp is active with 1 stacks 1 is current (= 0x8883dc88)
No Mdl: No System Buffer: Thread 888f8950:  Irp stack trace.
cmd  flg cl Device   File     Completion-Context
>[  d, 0]   5  1 88515ae8 888f82f0 00000000-00000000    pending
\FileSystem\Npfs
Args: 00000000 00000000 00110008 00000000

891204c8: Irp is active with 1 stacks 1 is current (= 0x89120538)
No Mdl: No System Buffer: Thread 889635b0:  Irp stack trace.
cmd  flg cl Device   File     Completion-Context
>[  3, 0]   0  1 88515ae8 84752028 00000000-00000000    pending
\FileSystem\Npfs
Args: 0000022a 00000000 00000000 00000000

89120ce8: Irp is active with 1 stacks 1 is current (= 0x89120d58)
No Mdl: No System Buffer: Thread 89212030:  Irp stack trace.
cmd  flg cl Device   File     Completion-Context
>[  3, 0]   0  1 88515ae8 8921be00 00000000-00000000    pending
\FileSystem\Npfs
Args: 0000022a 00000000 00000000 00000000
Searching NonPaged pool (80000000 : ffc00000) for Tag: Irp?

[...]

892cbe48: Irp is active with 9 stacks 9 is current (= 0x892cbfd8)
No Mdl: No System Buffer: Thread 892add78:  Irp stack trace.
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
>[  c, 2]   0  1 8474a020 892c8c80 00000000-00000000    pending
\FileSystem\Ntfs
Args: 00000800 00000002 00000000 00000000

892daa88: Irp is active with 4 stacks 4 is current (= 0x892dab64)
No Mdl: System buffer=831559c8: Thread 8322c8e8:  Irp stack trace.
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
>[  e,2d]   5  1 884ba750 83190c40 00000000-00000000    pending
\Driver\AFD
Args: 890cbc44 890cbc44 88e55297 8943b6c8

892ea4e8: Irp is active with 4 stacks 4 is current (= 0x892ea5c4)
No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  Pending has been returned
cmd  flg cl Device   File     Completion-Context
[  0, 0]   0  2 00000000 00000000 00000000-00000000

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

Args: 00000000 00000000 00000000 00000000
[  f, 0]   0  2 83a34bb0 00000000 84d779ed-88958050
\Driver\atapi CLASSPNP!ClasspMediaChangeDetectionCompletion
Args: 88958050 00000000 00000000 83992d10
>[  0, 0]   2  0 891ee030 00000000 00000000-00000000
\Driver\cdrom
Args: 00000000 00000000 00000000 00000000

8933fcb0: Irp is active with 1 stacks 1 is current (= 0x8933fd20)
No Mdl: No System Buffer: Thread 84753d78:  Irp stack trace.
cmd  flg cl Device   File     Completion-Context
>[  3, 0]   0  1 88515ae8 84759f40 00000000-00000000    pending
\FileSystem\Npfs
Args: 0000022a 00000000 00000000 00000000

893cf550: Irp is active with 1 stacks 1 is current (= 0x893cf5c0)
No Mdl: No System Buffer: Thread 888fd3b8:  Irp stack trace.
cmd  flg cl Device   File     Completion-Context
>[  3, 0]   0  1 88515ae8 834d30d0 00000000-00000000    pending
\FileSystem\Npfs
Args: 00000400 00000000 00000000 00000000

893da468: Irp is active with 6 stacks 7 is current (= 0x893da5b0)
Mdl=892878f0: No System Buffer: Thread 00000000:  Irp is completed.  Pending has been returned
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
[  f, 0]   0  0 84b3e028 00000000 9747fcd0-00000000
\Driver\usbehci USBSTOR!USBSTOR_CswCompletion
Args: 00000000 00000000 00000000 00000000
[  f, 0]   0  0 892ba8f8 00000000 84d780ce-8328e0f0
\Driver\USBSTOR CLASSPNP!TransferPktComplete
Args: 00000000 00000000 00000000 00000000

893efb00: Irp is active with 10 stacks 11 is current (= 0x893efcd8)
Mdl=83159378: No System Buffer: Thread 82b7f828:  Irp is completed.  Pending has been returned
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
[  3, 0]   0  0 885a55b8 00000000 81614138-00000000
\Driver\disk partmgr!PmReadWriteCompletion
Args: 00000000 00000000 00000000 00000000
[  3, 0]   0  0 89257c90 00000000 8042e4d4-831caab0
\Driver\partmgr volmgr!VmpReadWriteCompletionRoutine
Args: 00000000 00000000 00000000 00000000
[  3, 0]   0  0 831ca9f8 00000000 84dad0be-00000000
\Driver\volmgr ecache!EcDispatchReadWriteCompletion
Args: 00000000 00000000 00000000 00000000
[  3, 0]   0  0 8319c020 00000000 84dcc4d4-8576f8ac
\Driver\Ecache volsnap!VspSignalCompletion
Args: 00000000 00000000 00000000 00000000

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

An advice to succeed in Software Technical Support:

They said : The dump came from the wrong site
He’s a page from the end of the dump
I said : The dump came from the right site
Took me just one look
<…>
With a little debugging
You will survive
With a little debugging
You will get by
Do what you want
Go your own way
in Technical Support.

Modern Talking

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

This is another tracing example of unified debugging patterns introduced previously.

- Analysis Patterns

Focus of Tracing

- Architectural Patterns

Debug Event Subscription / Notification

- Design Patterns

Shared Debug Event State

- Implementation Patterns

Shared Variable

- Usage Patterns

Saving a memory address obtained at a breakpoint event in a debugger pseudo-register for use at later breakpoint events

Debugging.tv published a case study for tracing window messages in WinDbg. There a pseudo-register is used to save a buffer address before GetMessage call and then to reuse it after the call. Please look at Event State Management slide on Frames episode 0×06 presentation. The full WinDbg log and the recording are available there too.

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

Based on ideas of Roman Jakobson about “marked” and “unmarked” categories we propose another pattern called Marked Message that groups trace messages based on having some feature or property. For example, marked messages may point to some domain of software activity such related to functional requirements and therefore may help in troubleshooting and debugging. Unmarked messages include all other messages that don’t say anything about such activities (although may include messages pointing to such activities indirectly we unaware of) or messages that say explicitly that no such activity has occurred. We can even borrow a notation of distinctive features from phonology and annotate any trace or log after analysis to compare it with a master trace, for example, compose the following list of software trace distinctive features:

session database queries [+]
session initialization [-]
socket activity [+]
process A launched [+]
process B launched [-]
process A exited [-]
[…]

Here [+] means the activity is present in the trace and [-]  means the activity is either undetected or definitely not present. Sometime a non-present activity can be a marked activity corresponding to all inclusive unmarked present activity (see, for example, No Activity pattern).

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

A WinDbg snippet from a multithreaded service:

0:2011> ~2012s
0:2012>

PS. Teaching WinDbg commands on the eve!

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

The beginning of a debugging tale:

He was debugging for 7 years and when he stopped and looked around he saw only 2 people left from the team of 50 strong technical support engineers.

Folktale

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

I created a special picture based on CPU and memory timing diagram (an optimistic version of the original computicart):

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

150 bugtations so far…

Program history has two sides, a computational and a human.

Philip Schaff

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

This is the first initiative for the year of software trace analysis: the first and unique software trace and log analysis training based entirely on patterns of software behavior. No longer you will be frustrated when opening a software trace with millions of messages from hundreds of software components, threads and processes.

Memory Dump Analysis Services (DumpAnalysis.com) organizes a training course:

Learn how to efficiently and effectively analyze software traces and logs from complex software environments. Covered popular software logs and trace formats from Microsoft and Citrix products and tools including Event Tracing for Windows (ETW) and Citrix Common Diagnostics Format (CDF). Learn how to use pioneering and innovative pattern-driven software problem behavior analysis to troubleshoot and debug software incidents.

If your are registered you are allowed to optionally submit your software traces and logs before the training. This will allow us in addition to the carefully constructed problems tailor additional examples to the needs of the attendees.

The training consists of 2 two-hour sessions and additional homework exercises. When you finish the training you additionally get:

1. A full transcript in PDF format (retail price $200)
2. 6 volumes of Memory Dump Analysis Anthology in PDF format (retail price $120)
3. A personalized attendance certificate with unique CID (PDF format)
4. Free Dump Analysis World Network membership including updates to full PDF transcript Q&A section

Prerequisites: Basic Windows troubleshooting.

Audience: Software technical support and escalation engineers, software maintenance engineers, system administrators.

Session 1: October 12, 2012 4:00 PM - 6:00 PM BST
Session 2: October 15, 2012 4:00 PM - 6:00 PM BST

Price: 210 USD

Space is limited.
Reserve your remote training seat now at:
https://student.gototraining.com/r/5287623225237732608

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

Making Software A Better World.

Dmitry Vostokov, Memory Dump Analysis Services

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

The number of software trace analysis patterns approaches the critical mass of 50 and we have decided to focus on software tracing and logging in the forthcoming year. Some books on tracing including Volume 7 of Memory Dump Analysis Anthology will be published by OpenTask during that year and our efforts will be to further advance software narratology, software trace linguistics, and software trace analysis in the context of memory dump analysis, generative debugging and modeling software behavior.

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

This is another stack trace related pattern that we call Empty Stack Trace. Here we might need to do manual stack trace reconstruction like in the following example:

0:002> ~2s
eax=00000070 ebx=0110fb94 ecx=00000010 edx=005725d8 esi=0110fe58 edi=00000d80
eip=7c82847c esp=0110efe0 ebp=0110eff0 iopl=0  nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000      efl=00000246
ntdll!KiFastSystemCallRet:
7c82847c c3              ret

0:002> kL
ChildEBP RetAddr
0110efdc 00000000 ntdll!KiFastSystemCallRet

0:002> !teb
TEB at 7ffdc000
ExceptionList:        0110f980
StackBase:            01110000
StackLimit:           0110d000
SubSystemTib:         00000000
FiberData:            00001e00
ArbitraryUserPointer: 00000000
Self:                 7ffdc000
EnvironmentPointer:   00000000
ClientId:             00000b04 . 00000bd0
RpcHandle:            00000000
Tls Storage:          00000000
PEB Address:          7ffda000
LastErrorValue:       87
LastStatusValue:      c000000d
Count Owned Locks:    0
HardErrorMode:        0

0:002> dps 0110d000 01110000
0110d000  00000000
0110d004  00000000
[...]
0110f63c  00001000
0110f640  0110f64c
0110f644  02b91ea8
0110f648  00001000
0110f64c  00000004
0110f650  0110f6f0
0110f654  0374669d DbgHelp!WriteFullMemory+0×3cd
0110f658  ffffffff
0110f65c  0110d000
0110f660  00000000
0110f664  0480f5c0
0110f668  00003000
0110f66c  0110f7b0
0110f670  0110d000
0110f674  00000000
0110f678  00000065
0110f67c  00003000
0110f680  0110d000
0110f684  00000000
0110f688  01010000
0110f68c  00000000
0110f690  00000004
0110f694  00060002
0110f698  00003000
0110f69c  00000000
0110f6a0  00001000
0110f6a4  00000004
0110f6a8  00020000
0110f6ac  00040004
0110f6b0  7ffe0000 SharedUserData
0110f6b4  00000000
0110f6b8  00001000
0110f6bc  00000000
0110f6c0  0480f5c0
0110f6c4  00000000
0110f6c8  04c4a000
0110f6cc  00000000
0110f6d0  000003c7
0110f6d4  00000000
0110f6d8  00023b17
0110f6dc  00000000
0110f6e0  01110000
0110f6e4  00000000
0110f6e8  0099f000
0110f6ec  00000000
0110f6f0  0110f704
0110f6f4  037469d6 DbgHelp!WriteDumpData+0×206
0110f6f8  0110f738
0110f6fc  0110f7b0
0110f700  00000000
0110f704  0110f868
0110f708  03747449 DbgHelp!MiniDumpProvideDump+0×359
0110f70c  0110f738
0110f710  0110f7b0
0110f714  02b91fb0
0110f718  00000000
0110f71c  00000000
0110f720  00000000
0110f724  02b91fb0
0110f728  00000000
0110f72c  00000000
[…]
0110ff1c  00000001
0110ff20  00000008
0110ff24  0000000a
0110ff28  33017f51 ModuleA!Run+0xde
0110ff2c  00000001
0110ff30  0110ff74
0110ff34  00f08898
0110ff38  00000000
0110ff3c  00f082a8
0110ff40  00000000
0110ff44  00000001
0110ff48  33017e33 ModuleA!ThreadProc+0×2c
0110ff4c  a9b21e1e
0110ff50  00000000
0110ff54  00000000
0110ff58  00f08898
0110ff5c  0110ff4c
0110ff60  0110ffac
0110ff64  0110ff9c
0110ff68  33054245
0110ff6c  9ba52ad2
0110ff70  00000000
0110ff74  0110ffac
0110ff78  78543433 msvcr90!_endthreadex+0×44
0110ff7c  00f082a8
0110ff80  a9b2b0d3
0110ff84  00000000
0110ff88  00000000
0110ff8c  00f08898
0110ff90  0110ff80
0110ff94  0110ff80
0110ff98  0110ffdc
0110ff9c  0110ffdc
0110ffa0  7858cf5e msvcr90!_except_handler4
0110ffa4  d0f887df
0110ffa8  00000000
0110ffac  0110ffb8
0110ffb0  785434c7 msvcr90!_endthreadex+0xd8
0110ffb4  00000000
0110ffb8  0110ffec
0110ffbc  77e6482f kernel32!BaseThreadStart+0×34
0110ffc0  00f08898
0110ffc4  00000000
0110ffc8  00000000
0110ffcc  00f08898
0110ffd0  00000000
0110ffd4  0110ffc4
0110ffd8  80833bcc
0110ffdc  ffffffff
0110ffe0  77e61a60 kernel32!_except_handler3
0110ffe4  77e64838 kernel32!`string’+0×98
0110ffe8  00000000
0110ffec  00000000
0110fff0  00000000
0110fff4  7854345e msvcr90!_endthreadex+0×6f
0110fff8  00f08898
0110fffc  00000000
01110000  00000130

0:002> k L=0110f650 0110f650  0110f650
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
0110f650 0374669d 0x110f650
0110f6f0 037469d6 DbgHelp!WriteFullMemory+0x3cd
0110f704 03747449 DbgHelp!WriteDumpData+0x206
0110f868 03747662 DbgHelp!MiniDumpProvideDump+0x359
0110f8dc 33050dd9 DbgHelp!MiniDumpWriteDump+0x1b2
[...]
0110fdfc 33031726 ModuleA!WriteExceptionMiniDump+0x50
0110fea0 33018c81 ModuleA!ThreadHung+0x6c
[...]
0110ff44 33017e33 ModuleA!Run+0xde
00000000 00000000 ModuleA!ThreadProc+0x2c

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

If you are impatient with !analyze -v you can always use a replacement command that shows and sets the context for the current exception so you can quickly get to the possible crashing point (signature):

0:000> .ecxr
eax=00000000 ebx=00000001 ecx=00000000 edx=0018fe40 esi=00426310 edi=00000111
eip=0041ff21 esp=0018f81c ebp=0018f850 iopl=0  nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b      efl=00010246
*** ERROR: Module load completed but symbols could not be loaded for TestWER.exe
TestWER+0x1ff21:
0041ff21 c7050000000000000000 mov dword ptr ds:[0],0  ds:002b:00000000=????????

0:000> kL
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0018f850 00403620 TestWER+0x1ff21
0018f860 0040382f TestWER+0x3620
0018f890 00402df6 TestWER+0x382f
0018f8b4 00409ef8 TestWER+0x2df6
0018f904 0040a792 TestWER+0x9ef8
0018f9a0 00406dea TestWER+0xa792
0018f9c0 00409713 TestWER+0x6dea
0018fa28 004097a2 TestWER+0x9713
0018fa48 76f66238 TestWER+0x97a2
0018fa74 76f668ea user32!InternalCallWinProc+0x23
0018faec 76f6cd1a user32!UserCallWinProcCheckWow+0x109
0018fb30 76f6cd81 user32!SendMessageWorker+0x581
0018fb54 74fb4e95 user32!SendMessageW+0x7f
0018fb74 74fb4ef7 comctl32!Button_NotifyParent+0x3d
0018fb90 74fb4d89 comctl32!Button_ReleaseCapture+0x113
0018fbf0 76f66238 comctl32!Button_WndProc+0xa18
0018fc1c 76f668ea user32!InternalCallWinProc+0x23
0018fc94 76f67d31 user32!UserCallWinProcCheckWow+0x109
0018fcf4 76f67dfa user32!DispatchMessageWorker+0x3bc
0018fd04 76f82292 user32!DispatchMessageW+0xf
0018fd30 0040618c user32!IsDialogMessageW+0x5f6
0018fd44 004071e2 TestWER+0x618c
0018fd50 00402dd3 TestWER+0x71e2
0018fd64 00408dc1 TestWER+0x2dd3
0018fd78 00403f35 TestWER+0x8dc1
0018fd90 00404090 TestWER+0x3f35
0018fd9c 00403f80 TestWER+0x4090
0018fda8 004040dd TestWER+0x3f80
0018fde0 00403440 TestWER+0x40dd
0018fe2c 004204ee TestWER+0x3440
0018fee4 0041fdf5 TestWER+0x204ee
0018fef8 0040fc3e TestWER+0x1fdf5
0018ff88 76ce3677 TestWER+0xfc3e
0018ff94 77b89f02 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77b89ed5 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

However, in case of multiple exceptions you still need to do stack trace collection analysis:

0:000> .ecxr
eax=00000030 ebx=7efde000 ecx=750d2dd9 edx=00000000 esi=00000000 edi=00000000
eip=770d280c esp=0037f828 ebp=0037f870 iopl=0  nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b      efl=00000202
KERNELBASE!DebugBreak+0x2:
770d280c cc              int     3

0:000> ~*k 6

.  0  Id: f00.f04 Suspend: 0 Teb: 7efdd000 Unfrozen
ChildEBP RetAddr
0037f1a4 770d0bdd ntdll!NtWaitForMultipleObjects+0x15
0037f240 7529162d KERNELBASE!WaitForMultipleObjectsEx+0x100
0037f288 75291921 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0037f2a4 752b9b2d kernel32!WaitForMultipleObjects+0x18
0037f310 752b9bca kernel32!WerpReportFaultInternal+0x186
0037f324 752b98f8 kernel32!WerpReportFault+0×70

1  Id: f00.f18 Suspend: 1 Teb: 7efda000 Unfrozen
ChildEBP RetAddr
0080f9ac 770d31bb ntdll!NtDelayExecution+0x15
0080fa14 770d3a8b KERNELBASE!SleepEx+0x65
0080fa24 752d28dd KERNELBASE!Sleep+0xf
0080fa38 752b98f8 kernel32!WerpReportFault+0×3f
0080fa48 752b9875 kernel32!BasepReportFault+0×20
0080fad4 77b10df7 kernel32!UnhandledExceptionFilter+0×1af

2  Id: f00.f1c Suspend: 1 Teb: 7efd7000 Unfrozen
ChildEBP RetAddr
00abf640 770d31bb ntdll!NtDelayExecution+0x15
00abf6a8 770d3a8b KERNELBASE!SleepEx+0x65
00abf6b8 752d28dd KERNELBASE!Sleep+0xf
00abf6cc 752b98f8 kernel32!WerpReportFault+0×3f
00abf6dc 752b9875 kernel32!BasepReportFault+0×20
00abf768 77b10df7 kernel32!UnhandledExceptionFilter+0×1af

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

When doing software behavior artifact collection, live debugging or postmortem memory dump analysis we must also take into consideration the possibility of Debugger Bugs. I classify them into hard and soft bugs. The former are those software defects and behavioral problems that result in further abnormal software behavior incidents like crashes and hangs. One example is this Microsoft KB article about DebugDiag. Soft debugger bugs usually manifest themselves as glitches in data output, nonsense or false positive diagnostics, for example, this excessive non-paged pool usage message in the output from !vm WinDbg command (see the corresponding MS KB article):

1: kd> !vm

*** Virtual Memory Usage ***
Physical Memory:     1031581 (   4126324 Kb)
Page File: \??\C:\pagefile.sys
Current:   4433524 Kb  Free Space:   4433520 Kb
Minimum:   4433524 Kb  Maximum:     12378972 Kb
Unimplemented error for MiSystemVaTypeCount
Available Pages:      817652 (   3270608 Kb)
ResAvail Pages:       965229 (   3860916 Kb)
Locked IO Pages:           0 (         0 Kb)
Free System PTEs:   33555714 ( 134222856 Kb)
Modified Pages:        15794 (     63176 Kb)
Modified PF Pages:     15793 (     63172 Kb)
NonPagedPool Usage: 88079121 ( 352316484 Kb)
NonPagedPoolNx Usage:  12885 (     51540 Kb)
NonPagedPool Max:     764094 (   3056376 Kb)
********** Excessive NonPaged Pool Usage *****
PagedPool 0 Usage:     35435 (    141740 Kb)
PagedPool 1 Usage:      3620 (     14480 Kb)
PagedPool 2 Usage:       573 (      2292 Kb)
PagedPool 3 Usage:       535 (      2140 Kb)
PagedPool 4 Usage:       538 (      2152 Kb)
PagedPool Usage:       40701 (    162804 Kb)
PagedPool Maximum:  33554432 ( 134217728 Kb)
Session Commit:         9309 (     37236 Kb)
Shared Commit:          6460 (     25840 Kb)
Special Pool:              0 (         0 Kb)
Shared Process:         5760 (     23040 Kb)
PagedPool Commit:      40765 (    163060 Kb)
Driver Commit:          2805 (     11220 Kb)
Committed pages:      212472 (    849888 Kb)
Commit limit:        2139487 (   8557948 Kb)

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

On the portal I published my vision of software tools as a service in the context of post-construction software problem solving. The main part is software problem description language (SPDL) which was previously introduced as Riemann programming language. I have decided to keep the name.

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