How do I get handles information from a full-dump of a windows process?


I'm trying to debug an issue with what may be handle leak. I have a dump created on a remote windows machine and I would like to see the handles information. I'm using WinDbg. I have seen some articles from the MSDN and from other sources, like, but I can't get it to work, so I need some help. I tried the next

  1. Using !handles or !devhandles - these have failed. I either get no export handles found or a failure to load kdexts. Apparently kernel debugging is not enabled.
  2. I found winxp/kdexts.dll in my path (given from .chain command) but it wouldn't load - .load kdexts yields `DebugExtensionInitializeFailed1 with error code 0x80004005.
  3. Using !handle - with !handle -? I get help for the command but when I try something else, I get "Unable to read handle information". For example,
  • !handle - I expected a full list of handles
  • !handle 0 0
  • !handle 0 0 file

My setup

  • The remote process is Windows server 2012 (64bit), just as my own machine
  • I'm using the latest WinDbg from the windows sdk 10
  • I have a full dump, created by right-clicking task manager

I need some help if possible

  1. Do I need to do kernel-debugging in order to view the list of handles from the dump?
  2. Is it possible at all to do kernel-debugging on a full dump created from task-manager? Or is it required that the dump be taken differently?
  3. How can I know if a given dump file includes the handle information?
  4. How can I use the !handle command properly?
  5. Is there any other alternative, such as using visual studio, another utility, etc.?

I'd appreciate any help !tamir

asked on Stack Overflow May 16, 2021 by tamir • edited May 16, 2021 by tamir

2 Answers


your dump was probably a dump taken without handle information
you may use dumpchk.exe that comes with windbg installation to see if Handle Stream exists in the dump
if you have control over dump creation check how to use .dump /ma with windbg

or you may also explore sysinternals procdump.exe

and also make sure you are using the correct bitted debugger for the dump in question

a sample path

D:\>dir /s /b "c:\Program Files (x86)\Windows Kits\10\Debuggers\cdb.exe"
c:\Program Files (x86)\Windows Kits\10\Debuggers\arm\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\arm64\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe

here is a sample dump creation with and without handle stream in the dump

:000> .dump /ma d:\madump.dmp
Creating d:\madump.dmp - mini user dump
Dump successfully written
0:000> .dump d:\nomadump.dmp
Creating d:\nomadump.dmp - mini user dump
Dump successfully written
0:000> q 

analysing both the dumps with dumpchk and checking for streams present

dumpchk nomadump.dmp > nomachk.txt
dumpchk madump.dmp > machk.txt

D:\>type machk.txt |grep -i number.*stream
NumberOfStreams 17

D:\>type nomachk.txt |grep -i number.*stream
NumberOfStreams 13


D:\>diff -y machk.txt nomachk.txt

Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64     Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
Loading Dump File [D:\madump.dmp]                             | Loading Dump File [D:\nomadump.dmp]
User Mini Dump File with Full Memory: Only application d      | User Mini Dump File: Only registers, stack and portions of me

----- User Mini Dump Analysis                                   ----- User Mini Dump Analysis

MINIDUMP_HEADER:                                                MINIDUMP_HEADER:
Version         A793 (A063)                                     Version         A793 (A063)
NumberOfStreams 17                                            | NumberOfStreams 13
Flags           441826                                        | Flags           40000
                0002 MiniDumpWithFullMemory                   <
                0004 MiniDumpWithHandleData                   <
                0020 MiniDumpWithUnloadedModules              <
                0800 MiniDumpWithFullMemoryInfo               <
                1000 MiniDumpWithThreadInfo                   <
                40000 MiniDumpWithTokenInformation                              40000 MiniDumpWithTokenInformation
                400000 MiniDumpWithIptTrace                   <

if you feel enterprising take a look here for some hints to deciphering a dump without windbg /dbgeng

forgot to post the result of doing !handle on both dumps

D:\>cdb -c "!handle;q" -z nomadump.dmp |awk /Reading/,/quit/"
0:000> cdb: Reading initial command '!handle;q'
ERROR: !handle: extension exception 0x80004002.
    "Unable to read handle information"

D:\>cdb -c "!handle;q" -z madump.dmp |awk /Reading/,/quit/"
0:000> cdb: Reading initial command '!handle;q'
Handle 0000000000000004
  Type          File
Handle 0000000000000128
  Type          Mutant
Handle 000000000000012c
Handle 0000000000000180
  Type          File
70 Handles
Type                            Count
None                            27
Event                           13
File                            8
Directory                       2
Mutant                          1
Semaphore                       2
Key                             6
IoCompletion                    2
TpWorkerFactory                 2
ALPC Port                       1
WaitCompletionPacket            6
answered on Stack Overflow May 16, 2021 by blabb • edited May 16, 2021 by blabb

Check the tool which was used for creating the crash dump. Perhaps it provides an option to include handle data.

  • Task Manager includes handle data by default

  • Visual Studio includes handle data by default

  • In WinDbg, .dump can be used with the /mh switch to include handle data. /ma is a shortcut for /mfFhut, so it also includes handle data.

  • ProcDump automatically includes handle data.

  • Windows Error Reporting LocalDumps can be configured with a Registry value called CustomDumpFlags.

  • If you create the dump programmatically yourself with MiniDumpWriteDump(), use MINIDUMP_TYPE::MiniDumpWithHandleData.

answered on Stack Overflow May 17, 2021 by Thomas Weller

User contributions licensed under CC BY-SA 3.0