Software Diagnostics Library

As the new decade is approaching (2011-2020) we would like to make a few previews and predictions:

- Increased complexity of software will bring more methods from biological, social sciences and humanities in addition to existing methods of automated debugging and computer science techniques

- Focus on first fault software problem solving (when aspect)

- Focus on pattern-driven software problem solving (how aspect)

- Fusion of debugging and malware analysis into a unified structural and behavioral pattern framework

- Visual debugging, memory and software trace visualization techniques

- Software maintenance certification

- Focus on domain-driven troubleshooting and debugging tools as a service (debugware TaaS)

- Focus on security issues related to memory dumps and software traces

- New scripting languages and programming language extensions for debugging

- The maturation of the science of memory snapshots and software traces (memoretics)

Imagining is not not limited to the above and more to come and explain in the forthcoming parts.

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

MAaaS includes 2 complementary DA+TA services:

1. Dump Analysis as a Service (DAaaS)
2. Trace Analysis as a Service (TAaaS)

Memory Dump Analysis Services is the first organization to provide such a service at an audit and certification levels.

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

Five volumes of cross-disciplinary Anthology (dubbed by the author “The Summa Memorianica”) lay the foundation of the scientific discipline of Memoretics (study of computer memory snapshots and their evolution in time) that is also called Memory Dump and Software Trace Analysis.ca

The 5th volume contains revised, edited, cross-referenced, and thematically organized selected DumpAnalysis.org blog posts about crash dump, software trace analysis and debugging written in February 2010 - October 2010 for software engineers developing and maintaining products on Windows platforms, quality assurance engineers testing software on Windows platforms, technical support and escalation engineers dealing with complex software issues, and security researchers, malware analysts and reverse engineers. The fifth volume features:

- 25 new crash dump analysis patterns
- 11 new pattern interaction case studies (including software tracing)
- 16 new trace analysis patterns
- 7 structural memory patterns
- 4 modeling case studies for memory dump analysis patterns
- Discussion of 3 common analysis mistakes
- Malware analysis case study
- Computer independent architecture of crash analysis report service
- Expanded coverage of software narratology
- Metaphysical and theological implications of memory dump worldview
- More pictures of memory space and physicalist art
- Classification of memory visualization tools
- Memory visualization case studies
- Close reading of the stories of Sherlock Holmes: Dr. Watson’s observational patterns
- Fully cross-referenced with Volume 1, Volume 2, Volume 3, and Volume 4

Product information:

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

• Paperback: 400 pages
• Publisher: Opentask (10 December 2010)
• ISBN-13: 978-1-906717-96-4

• Hardcover: 400 pages
• Publisher: Opentask (10 December 2010)
• ISBN-13: 978-1-906717-97-1

Back cover features memory space art image Hot Computation: Memory on Fire.

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

If you develop and debug user space applications (and/or doing crash dump analysis in user space) or specialize in user space security and you want to understand Windows kernel dumps and device drivers better (and probably start writing your own kernel tools) or understand malware rootkits better here is the reading list I found the most effective over the last 7 years:

0.0. Read and re-read Windows Internals book in parallel while reading all other books. I read all editions by the way. It will show you the big picture and useful WinDbg commands and techniques but you need to read device driver books to fill the gaps and be confident in kernel space:

0.1. Start with The Windows 2000 Device Driver Book: A Guide for Programmers. This short book will show you the basics and you can start writing your drivers and kernel tools immediately.

0.2. Next read Windows NT Device Driver Development book to consolidate your knowledge. This book has been reprinted by OSR (I own the original New Riders Press edition):

0.3. Don’t stop here. Read Developing Windows NT Device Drivers: A Programmer’s Handbook. This is the very good book explaining everything in great detail and good pictures. You will finally understand various buffering methods.

0.4. Continue with WDM drivers and modern presentation: Programming the Microsoft Windows Driver Model. Must read even if your drivers are not WDM.

0.5. Finally read Developing Drivers with the Windows Driver Foundation book. It also covers ETW (event tracing for Windows), WinDbg extensions, PREfast and static driver verifier.

0.6. There is a forthcoming book Windows 7 Device Driver at the time of this writing that also covers WDF so you might want to start with #0.6 and continue with #0.5 as a reference:

Additional reading (not including DDK Help which you will use anyway) can be done in parallel after finishing “Windows NT Device Driver Development” book:

1.1. OSR NT Insider articles. I have their full printed collection 1996 - 2006 plus all the latest issues (looks like print editions are discontinued and the new ones are only digital):

http://www.osronline.com/

1.2. Windows NT File System Internals reprinted by OSR (I have the original O’Reilly edition):

1.3. Windows NT/2000 Native API Reference is fun to browse occasionally and indispensable if you don’t have access to Windows source code:

1.4. Rootkits: Subverting the Windows Kernel book will show you Windows kernel from the hacker perspective. In addition you will find the overview of kernel areas not covered in other books.

1.5. The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System is another excellent book that is up to date and explains kernel staff from ab initio. I’m reading it at the time of this writing and recommend it to read first or in parallel to all other books:

Of course, you must know C language and its idioms really well. Really know it down to assembly language level! I’ll publish other reading lists soon including reverse engineering classics. Stay tuned.

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

Motivated by the existence of London School of Economics (LSE) I just founded DSS. The program to be communicated soon and includes general memory dump and software trace analysis as a foundation for security. I like the name very much because of its additional meaning:

DUmps Binary Logs INternals

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

I detour for MARS expedition. You may also call it Memory Analysis Report System as malware analysis is always exploration of memory (in general). Why is this sudden change of course? After reading Gilles Deleuze I want to broaden the concept of “malware” and give it new orientation and direction of thinking. Beside that I also want new challenges after many years of research in pattern-driven memory dump and software trace analysis of abnormal software behaviour.

You may have also noticed small restructuring (rebranding) of this blog and DumpAnalysis.org headers.

See you there

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

As a practical example of applying behavioral and structural pattern analysis of computer memory and traces OpenTask plans to publish the following title next year:

• Title: Malware Patterns: Structure and Behavior of Computer Adware, Crimeware, Rootkits, Scareware, Spyware, Trojans, Viruses, Victimware and Worms
• Author: Dmitry Vostokov
• Paperback: 1200 pages
• Publisher: OpenTask (October 2011)
• ISBN-13: 978-1-908043-01-6

The inclusion of victimware is necessary because of the effects of defective malware.

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

One of my home computers got infected. I confess that I don’t have an antivirus because I’m conscious while browsing Internet (the last infected machine I had was an MSDOS one) so perhaps one of my family members was less careful. I paid attention to the possible infection when IE started crashing when I was pushing a login button on one of online banking websites. However I didn’t pay enough attention because it was a heap corruption (see my previous case study) and simply switched to another non-crashing browser vendor such as Apple Safari. Since then IE was crashing periodically when I was pushing various admin buttons in WordPress but I didn’t pay much attention too because it was still heap corruption and I was thinking it was a script processing defect, waiting for a new IE update. Until one day explorer.exe crashed as well when I was entering a password for an ftp account. Here’s the stack trace that I got after opening a crash dump in WinDbg:

0:030> kL 100
ChildEBP RetAddr
0663e9c4 76f05610 ntdll!KiFastSystemCallRet
0663e9c8 7706a5d7 ntdll!NtWaitForMultipleObjects+0xc
0663ea64 7706a6f0 kernel32!WaitForMultipleObjectsEx+0×11d
0663ea80 770de2a5 kernel32!WaitForMultipleObjects+0×18
0663eaec 770de4d1 kernel32!WerpReportFaultInternal+0×16d
0663eb00 770bff4d kernel32!WerpReportFault+0×70
0663eb8c 76f17fc1 kernel32!UnhandledExceptionFilter+0×1b5
0663eb94 76ea9bdc ntdll!__RtlUserThreadStart+0×6f
0663eba8 76ea4067 ntdll!_EH4_CallFilterFunc+0×12
0663ebd0 76f05f79 ntdll!_except_handler4+0×8e
0663ebf4 76f05f4b ntdll!ExecuteHandler2+0×26
0663eca4 76f05dd7 ntdll!ExecuteHandler+0×24
0663eca4 93181a08 ntdll!KiUserExceptionDispatcher+0xf
WARNING: Frame IP not in any known module. Following frames may be wrong.
0663efa0 0321aaaf 0×93181a08
0663efac 6b887974 0×321aaaf
0663efbc 6b8973ad msieftp!InternetCloseHandleWrap+0×10
0663f810 6b897fbf msieftp!CFtpSite::_QueryServerFeatures+0×57
0663fa50 6b8981ae msieftp!CFtpSite::_LoginToTheServer+0×235
0663fa94 6b88b39e msieftp!CFtpSite::GetHint+0xe8
0663fab4 6b88b412 msieftp!CFtpDir::GetHint+0×1f
0663fae4 6b88ed38 msieftp!CFtpDir::WithHint+0×49
0663fb10 6b88eda4 msieftp!CFtpEidl::_Init+0×6e
0663fb2c 7584ecb4 msieftp!CFtpEidl::Next+0×41
0663fb64 7584f63b shell32!CEnumThread::_EnumFolder+0×65
0663fb80 7584f5ba shell32!CEnumThread::_RunEnum+0×6f
0663fb8c 7645c2c9 shell32!CEnumThread::s_EnumThreadProc+0×14
0663fc10 7706d0e9 shlwapi!WrapperThreadProc+0×11c
0663fc1c 76ee19bb kernel32!BaseThreadInitThunk+0xe
0663fc5c 76ee198e ntdll!__RtlUserThreadStart+0×23
0663fc74 00000000 ntdll!_RtlUserThreadStart+0×1b

Notice 0×321aaaf address. We see that wininet function was hooked by a code running in 0×0321XXXX range:

0:030> ub 6b887974
msieftp!InternetOpenWrap+0×46:
6b887963 cc              int     3
msieftp!InternetCloseHandleWrap:
6b887964 8bff            mov     edi,edi
6b887966 55              push    ebp
6b887967 8bec            mov     ebp,esp
6b887969 56              push    esi
6b88796a ff7508          push    dword ptr [ebp+8]
6b88796d 33f6            xor     esi,esi
6b88796f e82e610100      call    msieftp!InternetCloseHandle (6b89daa2)

0:030> u 6b89daa2
msieftp!InternetCloseHandle:
6b89daa2 ff2500278a6b    jmp     dword ptr [msieftp!_imp__InternetCloseHandle (6b8a2700)]
msieftp!_imp_load__InternetConnectW:
6b89daa8 b834278a6b      mov     eax,offset msieftp!_imp__InternetConnectW (6b8a2734)
6b89daad e9b4feffff      jmp     msieftp!_tailMerge_WININET_dll (6b89d966)
6b89dab2 cc              int     3
6b89dab3 cc              int     3
6b89dab4 cc              int     3
6b89dab5 cc              int     3
6b89dab6 cc              int     3

0:030> dp 6b8a2700 l1
6b8a2700  76dc9088

0:030> u 76dc9088
wininet!InternetCloseHandle:
76dc9088 e9031a458c      jmp     0321aa90
76dc908d 51              push    ecx
76dc908e 51              push    ecx
76dc908f 53              push    ebx
76dc9090 56              push    esi
76dc9091 57              push    edi
76dc9092 33db            xor     ebx,ebx
76dc9094 33ff            xor     edi,edi

0:030> u 0321aa90
0321aa90 55              push    ebp
0321aa91 8bec            mov     ebp,esp
0321aa93 837d0800        cmp     dword ptr [ebp+8],0
0321aa97 740c            je      0321aaa5
0321aa99 8b4508          mov     eax,dword ptr [ebp+8]
0321aa9c 50              push    eax
0321aa9d e82eedffff      call    032197d0
0321aaa2 83c404          add     esp,4

This address range was not on a loaded module list so I used image scanning command to detect Hidden Module:

0:030> .imgscan
MZ at 00080000, prot 00000002, type 01000000 - size 2cd000
Name: explorer.exe
MZ at 003d0000, prot 00000002, type 00040000 - size 2000
MZ at 018a0000, prot 00000008, type 00040000 - size 7000
MZ at 031c0000, prot 00000008, type 00040000 - size 3000
MZ at 031d0000, prot 00000002, type 01000000 - size c000
Name: DLAAPI_W.DLL
MZ at 03210000, prot 00000040, type 00020000 - size 1d000
[…]

!dh command was not showing any useful hints so I dumped the whole address range of that Unknown Component and found strange strings inside:

0:030> db 03210000 03210000+1d000
[...]
032246d0  2a 00 00 00 2a 00 00 00-42 6c 61 63 6b 77 6f 6f  *...*...Blackwoo
032246e0  64 50 52 4f 00 00 00 00-46 69 6e 61 6d 44 69 72  dPRO....FinamDir
032246f0  65 63 74 00 47 72 61 79-42 6f 78 00 4d 62 74 50  ect.GrayBox.MbtP
03224700  52 4f 00 00 4c 61 73 65-72 00 00 00 4c 69 67 68  RO..Laser...Ligh
03224710  74 53 70 65 65 64 00 00-4c 54 47 72 6f 75 70 00  tSpeed..LTGroup.
03224720  4d 62 74 00 53 63 6f 74-54 72 61 64 65 72 00 00  Mbt.ScotTrader..
03224730  53 61 78 6f 54 72 61 64-65 72 00 00 00 00 00 00  SaxoTrader......
03224740  50 72 6f 67 72 61 6d 3a-20 20 20 25 73 0d 0a 55  Program:   %s..U
03224750  73 65 72 6e 61 6d 65 3a-20 20 25 73 0d 0a 50 61  sername:  %s..Pa
03224760  73 73 77 6f 72 64 3a 20-20 25 73 0d 0a 41 63 63  ssword:  %s..Acc
03224770  6f 75 6e 74 4e 4f 3a 20-25 73 0d 0a 53 65 72 76  ountNO: %s..Serv
03224780  65 72 3a 20 20 20 20 25-73 0d 0a 00 5c 00 00 00  er:    %s...\...
03224790  25 73 20 25 73 00 00 00-25 73 00 00 50 52 4f 43  %s %s...%s..PROC
032247a0  45 53 53 4f 52 5f 49 44-45 4e 54 49 46 49 45 52  ESSOR_IDENTIFIER
032247b0  00 00 00 00 25 64 00 00-25 30 32 58 00 00 00 00  ....%d..%02X....
032247c0  30 00 00 00 2c 00 00 00-25 30 32 58 00 00 00 00  0...,...%02X....
[...]
03225000  01 01 00 00 5c 00 63 00-68 00 6b 00 6e 00 74 00  ....\.c.h.k.n.t.
03225010  66 00 73 00 2e 00 65 00-78 00 65 00 00 00 00 00  f.s...e.x.e.....
03225020  5c 00 63 00 68 00 6b 00-6e 00 74 00 66 00 73 00  \.c.h.k.n.t.f.s.
03225030  2e 00 64 00 61 00 74 00-00 00 00 00 a6 b7 04 5e  ..d.a.t........^
[...]

I didn’t pay attention to chkntfs.exe but did a search for SaxoTrader string in all files using findstr command and found chkntfs.exe as a system file in Start Menu \ Programs \ Startup folder in roaming user AppData. I couldn’t remove it so I had to boot in command line mode to do that. The crashes were gone since that. I double checked various iexplore.exe crash dumps saved previously and found the same module loaded, for example:

0:005> .imgscan
MZ at 00040000, prot 00000040, type 00020000 - size 1d000
MZ at 00340000, prot 00000002, type 01000000 - size 9c000
Name: iexplore.exe
[…]

Here we consider IE and Explorer as victimware of malware.

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

Previously I introduced Hooked Functions pattern where I used !chkimg WinDbg command and today after accidentally discovering yet another patched DLL module in one process I created this simple command to check all modules:

!for_each_module !chkimg -lo 50 -d !${@#ModuleName} -v

0:000:x86> !for_each_module !chkimg -lo 50 -d !${@#ModuleName} -v
[...]
Scanning section:    .text
Size: 74627
Range to scan: 71c01000-71c13383
71c02430-71c02434  5 bytes - WS2_32!WSASend
[ 8b ff 55 8b ec:e9 cb db 1c 0d ]
71c0279b-71c0279f  5 bytes - WS2_32!select (+0x36b)
[ 6a 14 68 58 28:e9 60 d8 15 0d ]
71c0290e-71c02912  5 bytes - WS2_32!WSASendTo (+0x173)
[ 8b ff 55 8b ec:e9 ed d6 1b 0d ]
71c02cb2-71c02cb6  5 bytes - WS2_32!closesocket (+0x3a4)
[ 8b ff 55 8b ec:e9 49 d3 19 0d ]
71c02e12-71c02e16  5 bytes - WS2_32!WSAIoctl (+0x160)
[ 8b ff 55 8b ec:e9 e9 d1 1e 0d ]
71c02ec2-71c02ec6  5 bytes - WS2_32!send (+0xb0)
[ 8b ff 55 8b ec:e9 39 d1 14 0d ]
71c02f7f-71c02f83  5 bytes - WS2_32!recv (+0xbd)
[ 8b ff 55 8b ec:e9 7c d0 17 0d ]
71c03c04-71c03c08  5 bytes - WS2_32!WSAGetOverlappedResult (+0xc85)
[ 8b ff 55 8b ec:e9 f7 c3 1f 0d ]
71c03c75-71c03c79  5 bytes - WS2_32!recvfrom (+0x71)
[ 8b ff 55 8b ec:e9 86 c3 16 0d ]
71c03d14-71c03d18  5 bytes - WS2_32!sendto (+0x9f)
[ 8b ff 55 8b ec:e9 e7 c2 13 0d ]
71c03da8-71c03dac  5 bytes - WS2_32!WSACleanup (+0x94)
[ 8b ff 55 8b ec:e9 53 c2 25 0d ]
71c03f38-71c03f3c  5 bytes - WS2_32!WSASocketW (+0x190)
[ 6a 20 68 08 40:e9 c3 c0 11 0d ]
71c0446a-71c0446e  5 bytes - WS2_32!connect (+0x532)
[ 8b ff 55 8b ec:e9 91 bb 18 0d ]
71c04f3b-71c04f3f  5 bytes - WS2_32!WSAStartup (+0xad1)
[ 6a 14 68 60 50:e9 c0 b0 29 0d ]
71c06162-71c06166  5 bytes - WS2_32!shutdown (+0x1227)
[ 8b ff 55 8b ec:e9 99 9e 12 0d ]
71c069e9-71c069ed  5 bytes - WS2_32!WSALookupServiceBeginW (+0x887)
[ 8b ff 55 8b ec:e9 12 96 0f 0d ]
71c06c91-71c06c95  5 bytes - WS2_32!WSALookupServiceNextW (+0x2a8)
[ 8b ff 55 8b ec:e9 6a 93 10 0d ]
71c06ecd-71c06ed1  5 bytes - WS2_32!WSALookupServiceEnd (+0x23c)
[ 8b ff 55 8b ec:e9 2e 91 0e 0d ]
71c090be-71c090c2  5 bytes - WS2_32!WSAEventSelect (+0x21f1)
[ 8b ff 55 8b ec:e9 3d 6f 20 0d ]
71c09129-71c0912d  5 bytes - WS2_32!WSACreateEvent (+0x6b)
[ 33 c0 50 50 6a:e9 d2 6e 22 0d ]
71c0938e-71c09392  5 bytes - WS2_32!WSACloseEvent (+0x265)
[ 6a 0c 68 c8 93:e9 6d 6c 24 0d ]
71c093d9-71c093dd  5 bytes - WS2_32!WSAWaitForMultipleEvents (+0x4b)
[ 8b ff 55 8b ec:e9 22 6c 1a 0d ]
71c093ea-71c093ee  5 bytes - WS2_32!WSAEnumNetworkEvents (+0x11)
[ 8b ff 55 8b ec:e9 11 6c 21 0d ]
71c09480-71c09484  5 bytes - WS2_32!WSARecv (+0x96)
[ 8b ff 55 8b ec:e9 7b 6b 1d 0d ]
71c0eecb-71c0eecf  5 bytes - WS2_32!WSACancelAsyncRequest (+0x5a4b)
[ 8b ff 55 8b ec:e9 30 11 26 0d ]
71c10d39-71c10d3d  5 bytes - WS2_32!WSAAsyncSelect (+0x1e6e)
[ 8b ff 55 8b ec:e9 c2 f2 26 0d ]
71c10ee3-71c10ee7  5 bytes - WS2_32!WSAConnect (+0x1aa)
[ 8b ff 55 8b ec:e9 18 f1 22 0d ]
71c10f9f-71c10fa3  5 bytes - WS2_32!WSAAccept (+0xbc)
[ 8b ff 55 8b ec:e9 5c f0 27 0d ]
Total bytes compared: 74627(100%)
Number of errors: 140
140 errors : !WS2_32 (71c02430-71c10fa3)
[...]

CMDTREE.TXT was also updated with this command.

- Dmitry Vostokov @ DumpAnalysis.org -

This is a new word I’ve just coined to describe applications heavily dependent on various hooks that are either injected by normal Windows hooking mechanism, registry or via more elaborate tricks like remote threads or patching code. Originally I thought of hookware but found that this term is already in use for completely different purpose.

Now I list various patterns in memory dumps that help in detection, troubleshooting and debugging of hooksware:

- Hooked Functions (user space)

- Hooked Functions (kernel space)

- Hooking Level

This is the primary detection mechanism for hooks that patch code.

See also Raw Pointer and Out-of-Module Pointer patterns.

- Hooked Modules

The WinDbg script to run when you don’t know which module was patched.

- Changed Environment

Loaded hooks shift other DLLs by changing their load address and therefore might expose dormant bugs.

- Insufficient Memory (module fragmentation)

Hooks loaded in the middle of address space limit the maximum amount of memory that can be allocated at once. For example, various virtual machines, like Java, reserve the big chunk of memory at the start up.

- No Component Symbols

We can get an approximate picture of what a 3rd-party hook module does by looking at its import table or in the case of patching by looking at the list of deviations returned by .chkimg command.

- Unknown Component

Might give an idea about the author of the hook.

- Coincidental Symbolic Information

Sometimes hooks are loaded at round addresses like 0×10000000 and these values are very frequently used as flags or constants too.

- Wild Code

When hooking goes wrong the execution path goes into the wild territory.

- Execution Residue

Here we can find various hooks that use normal Windows hooking mechanism. Sometimes the search for “hook” word in symbolic raw stack output of dds command reveals them but beware of Coincidental Symbolic Information. See also Raw Stack Analysis Scripts page.

- Message Hooks - Modeling Example

Windows message hooking pattern example.

- Hidden Module

Some hooks may hide themselves.

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

Sometimes we look for modules that were loaded and unloaded at some time. lm command lists unloaded modules but some of them could be mapped to address space without using runtime loader. The latter case is common for drm-type protection tools, rootkits, malware or crimeware which can influence a process execution. In such cases we can hope that they still remain in virtual memory and search for them. WinDbg .imgscan command greatly helps in identifying MZ/PE module headers. The following example just illustrates this command without implying that the found module did any harm:

0:000> .imgscan
MZ at 000d0000, prot 00000002, type 01000000 - size 6000
  Name: usrxcptn.dll
MZ at 00350000, prot 00000002, type 01000000 - size 9b000
  Name: ADVAPI32.dll
MZ at 00400000, prot 00000002, type 01000000 - size 23000
  Name: javaw.exe
MZ at 01df0000, prot 00000002, type 01000000 - size 8b000
  Name: OLEAUT32.dll
MZ at 01e80000, prot 00000002, type 01000000 - size 52000
  Name: SHLWAPI.dll
[…]

We don’t see usrxcptn in either loaded or unloaded module lists:

0:002> lm
start    end        module name
00350000 003eb000   advapi32  
00400000 00423000   javaw    
01df0000 01e7b000   oleaut32 
01e80000 01ed2000   shlwapi 
[...]

Unloaded modules:

This is why I call this pattern Hidden Module. We can use Unknown Component pattern to see the module resources if present in memory:

0:002> !dh 000d0000

[...]

SECTION HEADER #4
   .rsrc name
     418 virtual size
    4000 virtual address
     600 size of raw data
    1600 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         (no align specified)
         Read Only

[...]

0:002> dc 000d0000+4000 L418
[…]
000d4140  […] n…z.)…F.i.l.
000d4150  […] e.D.e.s.c.r.i.p.
000d4160  […] t.i.o.n…..U.s.
000d4170  […]   e.r. .D.u.m.p. .
000d4180  […] U.s.e.r. .M.o.d.
000d4190  […] e. .E.x.c.e.p.t.
000d41a0  […] i.o.n. .D.i.s.p.
000d41b0  […] a.t.c.h.e.r…..

0:002> du 000d416C
000d416c  "User Dump User Mode Exception Di"
000d41ac  "spatcher"

This component seems to be loaded or mapped only if userdump package was fully installed where usrxcptn.dll is a part of its redistribution. Although from the memory dump comment we also see that the dump was taken manually using command line userdump.exe we see that the full userdump package was additionally installed which was probably not necessary (see Correcting Microsoft article about userdump.exe):

Loading Dump File [javaw.dmp]
User Mini Dump File with Full Memory: Only application data is available

Comment: 'Userdump generated complete user-mode minidump with Standalone function on COMPUTER-NAME'

- Dmitry Vostokov @ DumpAnalysis.org -