Software Diagnostics Library

I was thinking about the universal character of debugging for quite some time and finally the following bugtation provided an inspiration for a new book title to be published during the Year of Debugging:

Title: Breaking the Bug: Debugging as a Natural Phenomenon
ISBN-13: 978-1906717377

More product details will be announced later.

Actually I believe in the mystical nature of various debugging numbers and sequences. For example, the ISBN number of this book ends in 377 which is the octal base equivalent of 0n255 or 0xFF.

- Dmitry Vostokov @ DumpAnalysis.org - 

“Breaking the” Bug: Debugging “as a Natural Phenomenon”

Daniel Clement Dennett, Breaking the Spell: Religion as a Natural Phenomenon

- Dmitry Vostokov @ DumpAnalysis.org -

“Diamonds are forever but bugs are an error.”

Narasimha Vedala, Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov

- Dmitry Vostokov @ DumpAnalysis.org -

Here are product details and covers for previously announced DLL List Landscape book:

• Title: DLL List Landscape: The Art from Computer Memory Space
• Author: Dmitry Vostokov
• Publisher: Opentask (15 December 2008)
• Language: English
• Product Dimensions: 21.6 x 21.6
• ISBN-13: 978-1-906717-36-0
• Paperback: 16 pages

Front cover:

Back cover:

- Dmitry Vostokov @ DumpAnalysis.org -

Thanks to shellexecute I got the news of this release. Remember, you can always access quick download links from www.windbg.org.

 Dmitry Vostokov @ DumpAnalysis.org -

DLL is also a recursive acronym for DLL List Landscape. OpenTask is going to publish soon the new full color book:

Title: DLL List Landscape: The Art from Computer Memory Space
ISBN-13: 978-1-906717-36-0

More details will be announced tomorrow.  

- Dmitry Vostokov @ DumpAnalysis.org -

Below is the list of patterns related to process heap corruption:

• Dynamic Memory Corruption (process heap)
• Double Free (process heap)

and two case studies involving heap corruption:

• Exception and deadlock: pattern cooperation
• Heap and spike: pattern cooperation

- Dmitry Vostokov @ DumpAnalysis.org -

This is a common pattern cooperation in user dumps coming from x64 environments. Its characteristic feature is stack trace collection that appears to be damaged or corrupt with lots of zeroed call sites and sometimes having UNICODE values in saved RSP:

0:001> ~*kL

   0  Id: 668.684 Suspend: 1 Teb: 000007ff`fffde000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`000afcb8 000007ff`7f1ee614 USER32!NtUserWaitMessage+0xa
00000000`000afcc0 000007ff`7f1adf7a SHELL32!CDesktopBrowser::_MessageLoop+0x287
00000000`000afd50 00000001`0001a46c SHELL32!SHDesktopMessageLoop+0x5c
00000000`000afd80 00000001`000231ba Explorer!ExplorerWinMain+0x6f1
00000000`000afec0 00000000`77d5964c Explorer!ModuleEntry+0x1c6
00000000`000aff80 00000000`00000000 kernel32!BaseProcessStart+0x29

   1  Id: 668.20c Suspend: 1 Teb: 000007ff`fffdc000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

   2  Id: 668.298 Suspend: 1 Teb: 000007ff`fffd9000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

   3  Id: 668.f34 Suspend: 1 Teb: 000007ff`fffd7000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

   4  Id: 668.824 Suspend: 1 Teb: 000007ff`fffd5000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

   5  Id: 668.820 Suspend: 1 Teb: 000007ff`fffae000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

   6  Id: 668.914 Suspend: 1 Teb: 000007ff`fffac000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`0342fb98 000007ff`7fd6ff61 ntdll!ZwReplyWaitReceivePortEx+0xa
00000000`0342fba0 000007ff`7fd45369 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0x2a5
00000000`0342feb0 000007ff`7fd65996 RPCRT4!RecvLotsaCallsWrapper+0x9
00000000`0342fee0 000007ff`7fd65d51 RPCRT4!BaseCachedThreadRoutine+0xde
00000000`0342ff50 00000000`77d6b6da RPCRT4!ThreadStartRoutine+0x21
00000000`0342ff80 00000000`00000000 kernel32!BaseThreadStart+0x3a

   7  Id: 668.8cc Suspend: 1 Teb: 000007ff`fffaa000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0x7

   8  Id: 668.1078 Suspend: 1 Teb: 000007ff`fffa8000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

#  9  Id: 668.1118 Suspend: 1 Teb: 000007ff`fffa4000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

  10  Id: 668.574 Suspend: 1 Teb: 000007ff`fffa2000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000020 00000000`00000000 0×0

  11  Id: 668.a54 Suspend: 1 Teb: 000007ff`fffa0000 Unfrozen
Child-SP          RetAddr           Call Site
90000000`0000679f 00000000`00000000 0x72505c74`6e656d65

  12  Id: 668.163c Suspend: 1 Teb: 000007ff`fffa6000 Unfrozen
Child-SP          RetAddr           Call Site
0000001e`00057000 00000000`00000000 0x575c3a43`00000075

  13  Id: 668.5b0 Suspend: 1 Teb: 000007ff`fff9e000 Unfrozen
Child-SP          RetAddr           Call Site
49575c3a`43000000 00000000`00000000 0x4e49575c`3a430000

  14  Id: 668.4c0 Suspend: 1 Teb: 000007ff`fff9c000 Unfrozen
Child-SP          RetAddr           Call Site
3a430000`00200004 00000000`00000000 0x43000000`1f0001c0

  15  Id: 668.774 Suspend: 1 Teb: 000007ff`fff9a000 Unfrozen
Child-SP          RetAddr           Call Site
00410044`00500050 00000000`00000000 0×6e006f`00690074

  16  Id: 668.17c0 Suspend: 1 Teb: 000007ff`fff98000 Unfrozen
Child-SP          RetAddr           Call Site
005c0029`00360038 00000000`00000000 0×500048`005c0029

However we notice ‘#’ in front of thread 9:

#  9  Id: 668.1118 Suspend: 1 Teb: 000007ff`fffa4000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0×0

This marks the thread that caught the exception. We can either switch to it by ~9s or using ~#s command:

0:010> ~#s
00000000`00000000 ??              ???

Now we look at thread raw stack data to search for any hidden exceptions and we find one indeed:

0:009> !teb
TEB at 000007fffffa4000
    ExceptionList:        0000000000000000
    StackBase:            0000000003000000
    StackLimit:           0000000002ff2000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 000007fffffa4000
    EnvironmentPointer:   0000000000000000
    ClientId:             0000000000000668 . 0000000000001118
    RpcHandle:            0000000000000000
    Tls Storage:          0000000000000000
    PEB Address:          000007fffffdb000
    LastErrorValue:       0
    LastStatusValue:      0
    Count Owned Locks:    0
    HardErrorMode:        0

0:010> dqs 0000000003232000  0000000003240000
00000000`03232000  00000000`00000000
00000000`03232008  00000000`00000000
00000000`03232010  00000000`00000000
[…]
00000000`02ffc8c8  00000000`77ef3202 ntdll!KiUserExceptionDispatcher+0×52
00000000`02ffc8d0  fffffa80`07186100
00000000`02ffc8d8  00000000`02ffc8d0
00000000`02ffc8e0  00000000`00000000
[…]

0:009> .cxr 00000000`02ffc8d0
rax=0000000000000000 rbx=0000000000000000 rcx=00000000671b4610
rdx=ffffffff9be48728 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=0000000002ffce68 rbp=00000000671b4610
 r8=0000000002ffccc0  r9=0000000000000000 r10=000068aa62010001
r11=00000000671b4610 r12=0000000000000000 r13=00000000000006a5
r14=00000000671b45d0 r15=7ffffffffffffffd
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
00000000`00000000 ??              ???

0:009> kL
  *** Stack trace for last set context - .thread/.cxr resets it
Child-SP          RetAddr           Call Site
00000000`02ffce68 00000000`67199841 0×0
00000000`02ffce70 00000000`67193188 DllA!DllUnregisterServer+0×8401
00000000`02ffd230 00000000`67194f93 DllA!DllUnregisterServer+0×1d48
00000000`02ffd350 000007ff`7ca9cae4 DllA!DllUnregisterServer+0×3b53
00000000`02ffd3f0 000007ff`7ca9d867 NETSHELL!GetPrimaryIPv6AddressForAdapter+0×64
00000000`02ffd720 000007ff`7ca1eb4f NETSHELL!CConnectionFolder::GetDetailsOf+0×62a
00000000`02ffdd20 000007ff`7f27f57f NETSHELL!CConnectionFolder::GetDetailsEx+0×21d
00000000`02ffe870 000007ff`7f27eea6 SHELL32!CNameSpaceItemUIProperty::GetPropertyDisplayValue+0xaf
00000000`02ffe910 000007ff`7f1e7bd4 SHELL32!CDetailsSectionInfoTask::RunInitRT+0×213
00000000`02fffc60 000007ff`7cec9c26 SHELL32!CRunnableTask::Run+0×52
00000000`02fffc90 000007ff`7ef773d8 BROWSEUI!CShellTaskScheduler_ThreadProc+0×1be
00000000`02fffd60 00000000`77eea78a SHLWAPI!ExecuteWorkItem+0×28
00000000`02fffd90 00000000`77eea99f ntdll!RtlpWorkerCallout+0×183
00000000`02fffec0 00000000`77eeac75 ntdll!RtlpExecuteWorkerRequest+0×63
00000000`02ffff00 00000000`77d6b6da ntdll!RtlpWorkerThread+0×71
00000000`02ffff80 00000000`00000000 kernel32!BaseThreadStart+0×3a

Checking disassembly we see that DllA module code dereferenced a NULL code pointer:

0:009> ub DllA!DllUnregisterServer+0×8401
DllA!DllUnregisterServer+0×83e4:
00000000`67199824 0100            add     dword ptr [rax],eax
00000000`67199826 00488b          add     byte ptr [rax-75h],cl
00000000`67199829 cdff            int     0FFh
00000000`6719982b 1568ad0100      adc     eax,1AD68h
00000000`67199830 85c0            test    eax,eax
00000000`67199832 0f85d8000000    jne     DllA!DllUnregisterServer+0×84d0 (00000000`67199910)
00000000`67199838 488bcd          mov     rcx,rbp
00000000`6719983b ff1547ad0100    call    qword ptr [DllA!DllUnregisterServer+0×23148 (00000000`671b4588)]

0:009> dq 00000000`671b4588
00000000`671b4588  00000000`00000000 00000000`00000000
00000000`671b4598  000007ff`77317e40 00000000`00000000
00000000`671b45a8  00000000`00000000 00000000`00000000
00000000`671b45b8  00000000`00000000 00000000`00000000
00000000`671b45c8  00000000`00000000 00000000`00000000
00000000`671b45d8  000007ff`77310000 00000000`01b81240
00000000`671b45e8  00000000`00000001 00000000`020c09c0
00000000`671b45f8  00000000`00000001 00000001`00000001

- Dmitry Vostokov @ DumpAnalysis.org -

Easy to remember 67^th bugtation: 6 days and 7 nights and especially

“Seven” debugging “nights.”

The interpretation of 0×7D9 (2009), The Year of Debugging

- Dmitry Vostokov @ DumpAnalysis.org -

DumpAnalysis.org jointly with OpenTask publisher announces forthcoming 2009 as

The Year of Debugging

More plans and projects will be announced soon with the new updated publishing roadmap! Stay tuned.

- Dmitry Vostokov @ DumpAnalysis.org -

Got this book yesterday in the post and started reading. Table of contents is amazing for its practical depth and breadth. If you want me to provide a review in a language of concurrency  (I’m reading many books in parallel) I would simply say one word:

Priority!

It simply means priority reading for any Windows software developer and maintainer. Invaluable for any engineer debugging complex software problems and analyzing Windows crash dumps. Simply because Microsoft OS and CLR developers use all this concurrent stuff and best practices described in the book so it is vital to be able recognize them in memory dumps. After reading this book you also get priority boost in your understanding of process and thread dynamics and your ability to plan, architect, design and implement concurrent applications and services.

Concurrent Programming on Windows (Microsoft .NET Development Series)

- Dmitry Vostokov @ DumpAnalysis.org -

Previously announced my old Resume and CV as a book was submitted to print and distribution worldwide this morning.

It features UML statechart diagrams on the following front cover I designed myself:

- Dmitry Vostokov @ DumpAnalysis.org -

“The” computer “is the only place where” a crash “comes before” hang.

Anonymous American Saying

- Dmitry Vostokov @ DumpAnalysis.org -

“… the” debugger “(my almighty” application ”) …”

Thomas Jefferson, TO JAMES MONROE, Paris Mar. 18. 1785

- Dmitry Vostokov @ DumpAnalysis.org -

A book can serve the role of CV but this weekend another idea got into my mind is to publish my old pre-Citrix times CV (1987 - 2003) as a book and as an example of a guy with CV-writing obsession like I had 5 - 8 years ago:

• Title: Resume and CV: As a Book
• Paperback: 16 pages
• Publisher: Opentask (01 Dec 2008)
• ISBN-13: 978-1-906717-34-6

Soon it should appear on Amazon and bookshops around the world. Now when someone asks me to send a CV I can send them a link to buy it.

- Dmitry Vostokov @ DumpAnalysis.org -

OpenTask, a publisher of my books, is about to release a notebook for bloggers. For details please visit the page:

Idea: Blogger’s Notebook

I found it indispensable to keep track of my own blog post ideas in a hardcopy format, work on several blog transformations into books and simultaneously keep track of work and home-related tasks.

- Dmitry Vostokov @ DumpAnalysis.org -

Noticed that my blog is clearly visible from outside my apartment window even in daylight:

- Dmitry Vostokov @ DumpAnalysis.org -

“Avoid” crashes and hangs, “but do not seek” total stability “- nothing so expensive as” total stability.

Sydney Smith, A Memoir of the Reverend Sydney Smith by his daughter, Lady Holland, with a Selection from his Letters

- Dmitry Vostokov @ DumpAnalysis.org -

Because of large book density on my table disasters are inevitable. And it happened a month ago. I spilled coffee. One bottom level book sank like Titanic. The book on top of it which I was browsing at that moment survived heavily damaged: 

Recently I noticed that spilled coffee left a mark on one book side. It is clearly visible ”1“ on the picture above.

- Dmitry Vostokov @ DumpAnalysis.org - 

“How can you say my” computation “is not a success?” Has it “not for more than sixty” days “got enough to” process “and escaped being” crashed?

Logan Pearsall Smith, Last Words

- Dmitry Vostokov @ DumpAnalysis.org -