Crash Dump Analysis

Reinterpreting Mr. Sherlock Holmes’ words (as heard by Dr. Watson) in this zero-paradigmatic (no word substitution) semantic suffixal bugtation:

“Stop, driver, stop!” Did he forget a stop code?

Sherlock Holmes, A Study in Scarlet, Part 1, 3: The Lauriston Gardens Mystery

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

This is a revised, edited, cross-referenced and thematically organized volume of selected DumpAnalysis.org blog posts about crash dump analysis and debugging written in July 2009 - January 2010 for software engineers developing and maintaining products on Windows platforms, quality assurance engineers testing software on Windows platforms and technical support and escalation engineers dealing with complex software issues. The fourth volume features:

- 13 new crash dump analysis patterns
- 13 new pattern interaction case studies
- 10 new trace analysis patterns
- 6 new Debugware patterns and case study
- Workaround patterns
- Updated checklist
- Fully cross-referenced with Volume 1, Volume 2 and Volume 3
- New appendixes

Product information:

• Title: Memory Dump Analysis Anthology, Volume 4
• Author: Dmitry Vostokov
• Language: English
• Product Dimensions: 22.86 x 15.24

• Paperback: 410 pages
• Publisher: Opentask (30 March 2010)
• ISBN-13: 978-1-906717-86-5

• Hardcover: 410 pages
• Publisher: Opentask (30 April 2010)
• ISBN-13: 978-1-906717-87-2

Back cover features memory space art image: Internal Process Combustion.

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

“Memory dumps are facts.”

I’m very excited to announce that Volume 3 is available in paperback, hardcover and digital editions:

Memory Dump Analysis Anthology, Volume 3

Table of Contents

In two weeks paperback edition should also appear on Amazon and other bookstores. Amazon hardcover edition is planned to be available in January 2010.

The amount of information was so voluminous that I had to split the originally planned volume into two. Volume 4 should appear by the middle of February together with Color Supplement for Volumes 1-4. 

- Dmitry Vostokov @ DumpAnalysis.org -

This is a revised, edited, cross-referenced and thematically organized volume of selected DumpAnalysis.org blog posts about crash dump analysis and debugging written in October 2008 - June 2009 for software engineers developing and maintaining products on Windows platforms, quality assurance engineers testing software on Windows platforms and technical support and escalation engineers dealing with complex software issues. The third volume features:

- 15 new crash dump analysis patterns
- 29 new pattern interaction case studies
- Trace analysis patterns
- Updated checklist
- Fully cross-referenced with Volume 1 and Volume 2
- New appendixes

Product information:

• Title: Memory Dump Analysis Anthology, Volume 3
• Author: Dmitry Vostokov
• Language: English
• Product Dimensions: 22.86 x 15.24

• Paperback: 404 pages
• Publisher: Opentask (20 December 2009)
• ISBN-13: 978-1-906717-43-8

• Hardcover: 404 pages
• Publisher: Opentask (30 January 2010)
• ISBN-13: 978-1-906717-44-5

Back cover features 3D computer memory visualization image.

- Dmitry Vostokov @ DumpAnalysis.org -

I resumed this week my reading notebook on Software Generalist blog with a top priority book to read every working day: Windows Internals, 5th edition. In reading notes I put what I find interesting for me (at this time) or related to Windows memory dump analysis or debugging and troubleshooting in general. For the latter case, sometimes I put additional references or even WinDbg examples from user, kernel and complete memory dumps in full color. Hope you find these notes useful too:

http://www.softwaregeneralist.com/category/notes-on-windows-internals/

- Dmitry Vostokov @ DumpAnalysis.org -

Following the success of Windows Debugging: Practical Foundations the following title will be published this summer:

Windows Device Drivers: Practical Foundations (ISBN: 978-0955832840)

Table of contents will be posted later.

Other planned titles:

X64 Windows Debugging: Practical Foundations (ISBN: 978-1906717568) 

Windows Multithreading: Practical Foundations (ISBN: 978-1906717742)

 Like Windows Debugging book, these forthcoming titles are based on my seminars. 

- Dmitry Vostokov @ DumpAnalysis.org -

Looking at one kernel memory dump from x64 Windows Server 2008 I noticed this API call (shown in blue):

0: kd> kL 100
Child-SP          RetAddr           Call Site
fffffa60`138f4720 fffff800`01875f8a nt!KiSwapContext+0x7f
fffffa60`138f4860 fffff800`0187776a nt!KiSwapThread+0x2fa
fffffa60`138f48d0 fffff800`01ab16d6 nt!KeWaitForSingleObject+0x2da
fffffa60`138f4960 fffff800`01ab1667 nt!FsRtlCancellableWaitForMultipleObjects+0x62
fffffa60`138f49c0 fffffa60`06c515e0 nt!FsRtlCancellableWaitForSingleObject+0x27
fffffa60`138f4a00 fffffa60`06c611dc rdbss!RxWaitForStableCondition+0x11c
fffffa60`138f4a40 fffffa60`06c61c07 rdbss!RxFindOrCreateConnections+0x44c
fffffa60`138f4b20 fffffa60`06c56840 rdbss!RxConstructVirtualNetRoot+0xb7
fffffa60`138f4bc0 fffffa60`06c6381a rdbss!RxFindOrConstructVirtualNetRoot+0x594
fffffa60`138f4d30 fffffa60`06c54c42 rdbss!RxCreateTreeConnect+0x13e
fffffa60`138f4dc0 fffffa60`06c2fbf6 rdbss!RxCommonCreate+0x20a
fffffa60`138f4e80 fffffa60`06c5191a rdbss!RxFsdCommonDispatch+0x786
fffffa60`138f4f70 fffffa60`07e4f21f rdbss!RxFsdDispatch+0x21a
fffffa60`138f4fe0 fffffa60`011e05f5 mrxsmb!MRxSmbFsdDispatch+0xbf
fffffa60`138f5020 fffffa60`011e0130 mup!MupiCallUncProvider+0x159
fffffa60`138f5090 fffffa60`011e17af mup!MupStateMachine+0x120
fffffa60`138f50e0 fffffa60`00d200b4 mup!MupCreate+0x2c3
fffffa60`138f5160 fffffa60`06d332d6 fltmgr!FltpCreate+0xa4
[...]
3rd party filter drivers
[...]
fffffa60`138f55a0 fffff800`01aefa59 nt!IopParseDevice+0x5e3
fffffa60`138f5740 fffff800`01af3944 nt!ObpLookupObjectName+0x5eb
fffffa60`138f5850 fffff800`01affee0 nt!ObOpenObjectByName+0x2f4
fffffa60`138f5920 fffff800`01b00a0c nt!IopCreateFile+0x290
fffffa60`138f59c0 fffff800`0186fdf3 nt!NtCreateFile+0x78
fffffa60`138f5a50 fffff800`01870300 nt!KiSystemServiceCopyEnd+0x13
fffffa60`138f5c58 fffffa60`06c91a5e nt!KiServiceLinkage
fffffa60`138f5c60 fffff800`018913d1 dfsc!DfscConnOpenIpcConnectionCallout+0xbe
fffffa60`138f5d20 fffffa60`06c91d08 nt!KeExpandKernelStackAndCalloutEx+0×2e1
fffffa60`138f5db0 fffffa60`06c9bbcc dfsc!DfscGetIpcConnection+0×1f0
fffffa60`138f5e30 fffffa60`06c9bb21 dfsc!DfscRmGetReferral+0×78
fffffa60`138f5ea0 fffffa60`06c91470 dfsc!DfscGetDomainDCReferral+0×31
fffffa60`138f5ef0 fffffa60`06c917ec dfsc!DfscRmValidateDomainIterate+0×5c
fffffa60`138f5f40 fffffa60`06c915f5 dfsc!DfscValidateReferral+0xa0
fffffa60`138f5fb0 fffffa60`06c917ec dfsc!DfscRmValidateRootGetParent+0×75
fffffa60`138f5fe0 fffffa60`06c90825 dfsc!DfscValidateReferral+0xa0
fffffa60`138f6050 fffffa60`06c93905 dfsc!DfscCmValidateState+0×79
fffffa60`138f6090 fffffa60`06c9e759 dfsc!DfscSurrogateCreate+0×7d
fffffa60`138f6100 fffffa60`011e03ab dfsc!DfscSurrogatePreProcess+0xb9
fffffa60`138f6130 fffffa60`011e014f mup!MupCallSurrogatePrePost+0×10b
fffffa60`138f6190 fffffa60`011e17af mup!MupStateMachine+0×13f
fffffa60`138f61e0 fffffa60`00d200b4 mup!MupCreate+0×2c3
fffffa60`138f6260 fffffa60`06d332d6 fltmgr!FltpCreate+0xa4
[…]
3rd party filter drivers
[…]
fffffa60`138f6610 fffff800`01aefa59 nt!IopParseDevice+0×5e3
fffffa60`138f67b0 fffff800`01af3944 nt!ObpLookupObjectName+0×5eb
fffffa60`138f68c0 fffff800`01ac22f1 nt!ObOpenObjectByName+0×2f4
fffffa60`138f6990 fffff800`0186fdf3 nt!NtQueryAttributesFile+0×134
fffffa60`138f6c20 00000000`77285e4a nt!KiSystemServiceCopyEnd+0×13

This API is mentioned in the following presentation and document and can also be found in WDK:

PPT: Windows Memory Management Advances

DOC: Advances in Memory Management 

KeExpandKernelStackAndCallout

Its 3rd parameter is the stack size and we can see it used in disassembly where r8d register is used for 3rd parameter according to x64 calling convention and rcx is used for the first parameter, a function procedure to be executed with a guaranteed kernel stack size:

0: kd> kv 100
Child-SP          RetAddr           : Args to Child                                                           : Call Site
[...]
fffffa60`138f5c60 fffff800`018913d1 : 00000000`00000000 fffff880`10d6d3f8 00000000`00000000 00000000`00000000 : dfsc!DfscConnOpenIpcConnectionCallout+0xbe
fffffa60`138f5d20 fffffa60`06c91d08 : fffffa60`06c919a0 fffffa60`138f5df0 fffff880`102128d0 fffffa60`138f5f10 : nt!KeExpandKernelStackAndCalloutEx+0×2e1
fffffa60`138f5db0 fffffa60`06c9bbcc : 00000000`00000000 fffff880`10d6d3f8 00000000`00000000 fffff880`10d6d460 : dfsc!DfscGetIpcConnection+0×1f0
[…]

0: kd> ub fffffa60`06c91d08
dfsc!DfscGetIpcConnection+0×1c6:
fffffa60`06c91cde xor     r9d,r9d
fffffa60`06c91ce1 mov     qword ptr [rsp+50h],rax
fffffa60`06c91ce6 mov     rax,qword ptr [dfsc!DfscGlobalData+0×138 (fffffa60`06c8d758)]
fffffa60`06c91ced mov     r8d,6000h
fffffa60`06c91cf3 mov     qword ptr [rsp+40h],rdi
fffffa60`06c91cf8 mov     byte ptr [rsp+58h],r11b
fffffa60`06c91cfd mov     qword ptr [rsp+20h],rax
fffffa60`06c91d02 call    qword ptr [dfsc!_imp_KeExpandKernelStackAndCalloutEx (fffffa60`06c8b0d0)]

0: kd> ub fffffa60`06c91cde
dfsc!DfscGetIpcConnection+0x199:
fffffa60`06c91cb1 488b88b8000000  mov     rcx,qword ptr [rax+0B8h]
fffffa60`06c91cb8 0fba61100a      bt      dword ptr [rcx+10h],0Ah
fffffa60`06c91cbd 450f42df        cmovb   r11d,r15d
fffffa60`06c91cc1 488b4338        mov     rax,qword ptr [rbx+38h]
fffffa60`06c91cc5 488d542440      lea     rdx,[rsp+40h]
fffffa60`06c91cca 488d0dcffcffff  lea     rcx,[dfsc!DfscConnOpenIpcConnectionCallout (fffffa60`06c919a0)]
fffffa60`06c91cd1 4889442448      mov     qword ptr [rsp+48h],rax
fffffa60`06c91cd6 488d842490000000 lea     rax,[rsp+90h]

It is good sign to see it used in file system stacks because in the past the fixed kernel stacks resulted in stack overflows and double faults:

Stack Overflow Pattern (kernel mode)

- Dmitry Vostokov @ DumpAnalysis.org -

As one of the new initiatives for the Year of Debugging  DumpAnalysis Portal will publish bimonthly full color 16 page publication called:

Debugged! MZ/PE: MagaZine for/from Practicing Engineers
The only serial publication dedicated entirely to Windows® debugging

The first issue is planned for March, 2009 and will have ISBN-13: 978-1-906717-38-4. If it goes well I’m planning to have ISSN number assigned to it too. More details will be announced soon.

- Dmitry Vostokov @ DumpAnalysis.org - 

Paperback edition of Memory Dump Analysis Anthology, Volume 2 is finally available on Amazon and Barnes & Noble. Search Inside is also available on Amazon. In addition, I updated the list of recommended books:

Listmania! Crash Dump Analysis and Debugging

Hardcover edition will be available on Amazon and B&N in 2-3 weeks.

- Dmitry Vostokov @ DumpAnalysis.org -

Seems railroad to it was a success: just got this message in my e-mail:

“Congratulations on passing your recent Microsoft Certification exam, inspiring confidence for your employer, your peers, and yourself with a widely-recognized validation of your skills on Microsoft technology.“

Because I haven’t done any exam since Windows Internals beta I assumed that I passed it and I was right! After registering at Microsoft certification site as MCP I was able to build my logo:

Here is the link to Exam 70-660 information and required skills:

http://www.microsoft.com/learning/en/us/Exams/70-660.aspx

- Dmitry Vostokov @ DumpAnalysis.org -

“Everything is memory dump.”

I’m very excited to announce that Volume 2 is available in paperback, hardcover and digital editions:

Memory Dump Analysis Anthology, Volume 2

In one or two weeks paperback edition should also appear on Amazon and other bookstores. Amazon hardcover edition is planned to be available by the end of October.

I’m often asked when Volume 3 is available and I currently plan to release it in October - November, 2009. In the mean time I’m planning to concentrate on other publishing projects. 

- Dmitry Vostokov @ DumpAnalysis.org -

The book is nearly finished and here is the final TOC:

Memory Dump Analysis Anthology, Volume 2: Table of Contents

- Dmitry Vostokov @ DumpAnalysis.org -

“An excellent precept for” programmers: “have a clear idea of all the” functions “and expressions you need, and you will find them.”

Ximénès Doudan, Pensées et fragments suivis des révolutions du goût

- Dmitry Vostokov @ DumpAnalysis.org -

“But perhaps the” OS “is suspended on the” finger “of some” developer.

Anton Chekhov, Notebook

- Dmitry Vostokov @ DumpAnalysis.org -

“You can take better care of your” code “than another can.”

Ralph Waldo Emerson, Journals

- Dmitry Vostokov @ DumpAnalysis.org -

This is the next scheduled book from Crash Dump Analysis Publishing Roadmap:

• Title: Windows® Debugging Notebook: Essential Concepts, WinDbg Commands and Tools
• Authors: Roberto Alexis Farah, Dmitry Vostokov
• Language: English
• Product Dimensions: 22.86 x 15.24

• ISBN-13: 978-1-906717-00-1
• Publisher: Opentask (1 December 2009)
• Paperback: 256 pages

• ISBN-13: 978-0-9558328-5-7
• Publisher: Opentask (1 February 2010)
• Hardcover (Cloth): 256 pages

Draft Table of Contents will be published next month together with a sample chapter.

- Dmitry Vostokov @ DumpAnalysis.org -

Due to demand from people that prefer ebooks I published Memory Dump Analysis Anthology, Volume 1 in a digital format that can be purchased in Crash Dump Analysis Store. This format has color pictures inside.

- Dmitry Vostokov @ DumpAnalysis.org -

There are some improvements in Vista and Windows Server 2008 regarding various WER callbacks to write user-defined data in the case of application crashes and hangs. See MSDN documentation:

What’s New in WER

However I have found that many engineers are not aware that the similar mechanism exists in kernel for many years:

Writing a Bug Check Callback Routine

You can check this data using !bugdump and .enumtag WinDbg commands:

0: kd> !bugdump
**** Dump of Bug Check Data ****
8526ba7c: Bug check callback record could not be read

We get “could not be read” message probably because for systems newer than Windows XP SP1 !bugdump command shows callback data written to memory after the crash dump was saved. So it is useful for live debugging only. However we can see that bugcheck callbacks form a linked list:

0: kd> dps 8526ba7c
8526ba7c  849eca7c
8526ba80  81b36ce0 nt!KeBugCheckCallbackListHead
8526ba84  858a7dea ndis!ndisBugcheckHandler
8526ba88  8526b438
8526ba8c  00000b28
8526ba90  8594dd76 ndis! ?? ::LNCPHCLB::`string’
8526ba94  90461ac0
8526ba98  00000001
8526ba9c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8526baa0  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8526baa4  85969274 ndis!ethFilterDprIndicateReceivePacket
8526baa8  8de66c5c bthpan!MpReturnPacket
8526baac  8526ea80
8526bab0  859495ef ndis!ndisSynchReturnPacketsForTranslation
8526bab4  8526b438
8526bab8  00000000

0: kd> !list -x "dps @$extret l10" 81b36ce0
81b36ce0  8526ba7c
81b36ce4  81ddbe40 hal!HalpCallbackRecord
81b36ce8  00000000
81b36cec  00000001
81b36cf0  00000000
81b36cf4  00000000
81b36cf8  00000101
81b36cfc  00000001
81b36d00  00000000
81b36d04  00000000
81b36d08  00000000
81b36d0c  00000000
81b36d10  00000000
81b36d14  00000000
81b36d18  00000000
81b36d1c  00000000

8526ba7c  849eca7c
8526ba80  81b36ce0 nt!KeBugCheckCallbackListHead
8526ba84  858a7dea ndis!ndisBugcheckHandler
8526ba88  8526b438
8526ba8c  00000b28
8526ba90  8594dd76 ndis! ?? ::LNCPHCLB::`string'
8526ba94  90461ac0
8526ba98  00000001
8526ba9c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8526baa0  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8526baa4  85969274 ndis!ethFilterDprIndicateReceivePacket
8526baa8  8de66c5c bthpan!MpReturnPacket
8526baac  8526ea80
8526bab0  859495ef ndis!ndisSynchReturnPacketsForTranslation
8526bab4  8526b438
8526bab8  00000000

849eca7c  849ea72c
849eca80  8526ba7c
849eca84  858a7dea ndis!ndisBugcheckHandler
849eca88  849ec438
849eca8c  00000b28
849eca90  8594dd76 ndis! ?? ::LNCPHCLB::`string'
849eca94  8fbe2ac0
849eca98  00000001
849eca9c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849ecaa0  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849ecaa4  859432ca ndis!ndisMIndicatePacket
849ecaa8  00000000
849ecaac  00000000
849ecab0  859495ef ndis!ndisSynchReturnPacketsForTranslation
849ecab4  849ec438
849ecab8  00000000

849ea72c  849c272c
849ea730  849eca7c
849ea734  858a7dea ndis!ndisBugcheckHandler
849ea738  849ea0e8
849ea73c  00000b28
849ea740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
849ea744  8fbe0770
849ea748  00000001
849ea74c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849ea750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849ea754  85969274 ndis!ethFilterDprIndicateReceivePacket
849ea758  00000000
849ea75c  00000000
849ea760  859495ef ndis!ndisSynchReturnPacketsForTranslation
849ea764  849ea0e8
849ea768  00000000

849c272c  849c172c
849c2730  849ea72c
849c2734  858a7dea ndis!ndisBugcheckHandler
849c2738  849c20e8
849c273c  00000b28
849c2740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
849c2744  8fbb8770
849c2748  00000001
849c274c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849c2750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849c2754  85969274 ndis!ethFilterDprIndicateReceivePacket
849c2758  85df579a tunmp!TunMpReturnPacket
849c275c  84a45538
849c2760  859495ef ndis!ndisSynchReturnPacketsForTranslation
849c2764  849c20e8
849c2768  00000000

849c172c  849a072c
849c1730  849c272c
849c1734  858a7dea ndis!ndisBugcheckHandler
849c1738  849c10e8
849c173c  00000b28
849c1740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
849c1744  8fbb7770
849c1748  00000001
849c174c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849c1750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849c1754  859432ca ndis!ndisMIndicatePacket
849c1758  00000000
849c175c  00000000
849c1760  859495ef ndis!ndisSynchReturnPacketsForTranslation
849c1764  849c10e8
849c1768  00000000

849a072c  8499d72c
849a0730  849c172c
849a0734  858a7dea ndis!ndisBugcheckHandler
849a0738  849a00e8
849a073c  00000b28
849a0740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
849a0744  8fb96770
849a0748  00000001
849a074c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849a0750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
849a0754  859432ca ndis!ndisMIndicatePacket
849a0758  00000000
849a075c  00000000
849a0760  859495ef ndis!ndisSynchReturnPacketsForTranslation
849a0764  849a00e8
849a0768  00000000

8499d72c  8499f72c
8499d730  849a072c
8499d734  858a7dea ndis!ndisBugcheckHandler
8499d738  8499d0e8
8499d73c  00000b28
8499d740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
8499d744  8fb93770
8499d748  00000001
8499d74c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8499d750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8499d754  859432ca ndis!ndisMIndicatePacket
8499d758  00000000
8499d75c  00000000
8499d760  859495ef ndis!ndisSynchReturnPacketsForTranslation
8499d764  8499d0e8
8499d768  00000000

8499f72c  81ddbe40 hal!HalpCallbackRecord
8499f730  8499d72c
8499f734  858a7dea ndis!ndisBugcheckHandler
8499f738  8499f0e8
8499f73c  00000b28
8499f740  8594dd76 ndis! ?? ::LNCPHCLB::`string'
8499f744  8fb95770
8499f748  00000001
8499f74c  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8499f750  85936767 ndis!ndisMDispatchReceiveNetBufferLists
8499f754  859432ca ndis!ndisMIndicatePacket
8499f758  00000000
8499f75c  00000000
8499f760  859495ef ndis!ndisSynchReturnPacketsForTranslation
8499f764  8499f0e8
8499f768  00000000

81ddbe40  81b36ce0 nt!KeBugCheckCallbackListHead
81ddbe44  8499f72c
81ddbe48  81dcebdc hal!HalpBugCheckCallback
81ddbe4c  00000000
81ddbe50  00000000
81ddbe54  81dc2550 hal!HalName
81ddbe58  03b9112c
81ddbe5c  00000001
81ddbe60  00000000
81ddbe64  00000000
81ddbe68  00000000
81ddbe6c  00000000
81ddbe70  6d46da80
81ddbe74  00000000
81ddbe78  00000000
81ddbe7c  00000000

Another WinDbg command .enumtag shows data written before saving a crash dump and therefore useful for postmortem crash dump analysis (binary output is removed for visual clarity):

0: kd> .enumtag
{BC5C008F-1E3A-44D7-988D86F6884C6758} - 0x5cd bytes
  ...$............
  ................
  Apple Inc..    M
  M21.88Z.009A.B00
  .0706281359.06/2
  8/07............
  ................
  .Apple Inc..Macm
  ini2,1.1.0.    
        .System SK
  UNumber.Napa Mac
  ................
  ..Apple Inc..Mac
  -F4208EAA.PVT. .
  .Part Compon
  ent.............
  ..........Apple
  Inc..Mac-F4208EA
  A.           . 
  ............J6H1
  :1-X CMOS CLEAR(
  default); J8H1:1
  -X BIOS RECOVERY
  ...........None.
  Ethernet........
  ...None.DVI.....
  ......None.USB0.
  ..........None.U
  SB1...........No
  ne.USB2.........
  ..None.USB3.....
  ....!.None.FireW
  ire0...........N
  one.Audio Line I
  n...........None
  .Audio Line Out.
  ..............Ai
  rPort........Int
  egrated Graphics
  Controller ....
  ....Yukon Ethern
  et Controller...
  .....Azalia Audi
  o Codec........S
  ATA........PATA.
  ..........#.....
  .............&.&
  .A..........Inte
  l(R) Core(TM)2 C
  PU         T.Int
  el(R) Corporatio
  n.U2E1.       ..
[...]
  .......Intel(R)
  Core(TM)2 CPU  
       T.Intel(R)
  Corporation.U2E
  1.       .......
[...]
  ...........DIMM0
  .BANK 0.0x2C0000
  0000000000.    
      .       .0x
  3848544636343634
  4844592D36363744
  3320....!.......
  .. .$........"..
  ...@.@..........
  ......DIMM1.BANK
  1.0x2C000000000
  00000.         
  .       .0x38485
  4463634363448445
  92D363637443320.
[...]
{6C7AC389-4313-47DC-9F34A8800A0FB56C} - 0x266 bytes
  ....~.M.H.z.....
  ......)...,...C.
  o.m.p.o.n.e.n.t.
  .I.n.f.o.r.m.a.
  t.i.o.n.........
  ..&...C.o.n.f.i.
  g.u.r.a.t.i.o.n.
  .D.a.t.a.......
  ........I.d.e.n.
  t.i.f.i.e.r.....
  ..B...x.8.6. .F.
  a.m.i.l.y. .6. .
  M.o.d.e.l. .1.5.
  .S.t.e.p.p.i.n.
  g. .2...(...P.r.
  o.c.e.s.s.o.r.N.
  a.m.e.S.t.r.i.n.
  g.......`...I.n.
  t.e.l.(.R.). .C.
  o.r.e.(.T.M.).2.
  .C.P.U. . . . .
  . . . . .T.5.6.
  0.0. . .@. .1...
  8.3.G.H.z..."...
  U.p.d.a.t.e. .S.
  i.g.n.a.t.u.r.e.
  ..............W.
  ......U.p.d.a.t.
  e. .S.t.a.t.u.s.
  ..............".
  ..V.e.n.d.o.r.I.
  d.e.n.t.i.f.i.e.
  r...........G.e.
  n.u.i.n.e.I.n.t.
  e.l.......M.S.R.
[...]
{D03DC06F-D88E-44C5-BA2AFAE035172D19} - 0x438 bytes
  ............Genu
  ntelineI....Genu
  ntelineI........
[...]
  ........Intel(R)
  Core(TMIntel(R)
  Core(TM........
  )2 CPU         T
  )2 CPU         T
  ........5600  @
  1.83GHz.5600  @
  1.83GHz.........
[...]
{E83B40D2-B0A0-4842-ABEA71C9E3463DD1} - 0x184 bytes
  APICh.....APPLE
  Apple00.....Loki
  _.......FACP....
  .aAPPLE Apple00.
  ....Loki_......>
  HPET8.....APPLE
  Apple00.....Loki
  _.......MCFG<...
  ..APPLE Apple00.
  ....Loki_.......
  ASF!.... .APPLE
  Apple00.....Loki
  _.......SBST0...
  ..APPLE Apple00.
  ....Loki_.......
  ECDTS....9APPLE
  Apple00.....Loki
  _.......SSDTO...
  .>APPLE SataPri.
  ....INTL... SSDT
  O....>APPLE Sata
  Pri.....INTL...
  SSDTO....>APPLE
  SataPri.....INTL
{270A33FD-3DA6-460D-BA893C1BAE21E39B} - 0xfc8 bytes
  ........H.......
  H.......H.......
[...]

Of course, this is much more useful if your drivers save additional data for troubleshooting and you have written a WinDbg extension to interpret it.

- Dmitry Vostokov @ DumpAnalysis.org -

I’m very proud to announce that it is finally available in both paperback and hardback. Why have I made available both editions? Because I personally prefer hardcover books. You can order the book today and it will be printed in 3-5 days (paperback) or 5-10 days (hardcover) and sent to you:

Memory Dump Analysis Anthology, Volume 1

Note: although listed on Amazon and other online bookstores it is not immediately available at these stores at the moment due to the late submission. I apologize for this. However, I expect that in a few weeks pre-orders taken there will be eventually fulfilled. In the mean time, if you want the book now, you can use the link above.

- Dmitry Vostokov @ DumpAnalysis.org -

Just noticed that this month Addison-Wesley Professional reprints in paperback its out of stock hardcover book originally published in 1999:

Developing Windows NT Device Drivers: A Programmer’s Handbook (paperback)

Highly recommended. Almost all book material is still relevant today even in the light of new WDF model. Please also see my post Moving to kernel space (updated references).

- Dmitry Vostokov @ DumpAnalysis.org -