I was working on a customer issue which involved debugging a dump.  The dump was generated via SQLDumper within Reporting Services.  So, the name of the dump was similar to SQLDmpr0001.mdmp.  When I opened the dump I saw the following:

Loading Dump File [C:\temp\SQLDmpr0001.mdmp]
User Mini Dump File with Full Memory: Only application data is available

Which tells me we actually have a full dump.  Well, that and the fact that the dump was almost 8GB.

Through the course of debugging, I had a need to run !handle to get some handle information.  This is what the output should look like for a specific handle:

0:000> !handle 50 f
Handle 0000000000000050
  Type             Event
  Attributes       0
  GrantedAccess    0x1f0003:
         Delete,ReadControl,WriteDac,WriteOwner,Synch
         QueryState,ModifyState
  HandleCount      2
  PointerCount     4
  Name             <none>
  No object specific information available

However, this is what I got when I tried running it on this particular dump:

0:050> !handle 510 f
ERROR: !handle: extension exception 0x80004002.
    "Unable to read handle information"

So, maybe that individual handle was bad, but running !handle also had the same issue.

0:050> !handle
ERROR: !handle: extension exception 0x80004002.
    "Unable to read handle information"

To be honest, this is the first time I’ve had to look at handle information in an RS Dump as most of the time I’m looking at the managed side of things, not the native side.  My thought at that point was that the dump collection didn’t actually grab handle related information.  This dump was collected with the following setting within rsreportserver.config

<!--  <Add Key="WatsonFlags" Value="0x0430" /> full dump-->
<!--  <Add Key="WatsonFlags" Value="0x0428" /> minidump -->
<!--  <Add Key="WatsonFlags" Value="0x0002" /> no dump-->
<Add Key="WatsonFlags" Value="0x0430"/>

430 showed full dump from the rsreportserver.config, but lets see what this actually means from sqldumper.

C:\Program Files\Microsoft SQL Server\100\Shared>sqldumper /?
Usage: sqldumper [ProcessID [ThreadId [Flags[:MiniDumpFlags] [SqlInfoPtr [DumpDir [ExceptionRecordPtr [ContextPtr [ExtraFile]]]]]]]] [-I<InstanceName>] [-S<ServiceName>][-remoteservers:[print|dump|freeze|resume|remote:guid\dumporigin\signature\localId\port\operationType]]
  Flags:
    dbgbreak            = 0x0001
    nominidump          = 0x0002
    validate_image      = 0x0004
    referenced_memory   = 0x0008
    all_memory          = 0x0010
    dump_all_threads    = 0x0020
    match_file_name     = 0x0040
    no_longer_used_flag = 0x0080
    verbose             = 0x0100
    wait_at_exit        = 0x0200
    send_to_watson      = 0x0400
    defaultflags        = 0x0800
    maximumdump         = 0x1000
    mini_and_maxdump    = 0x2000
    force_send_to_watson= 0x4000
    full_filtered_dump  = 0x8000

  MiniDumpFlags:
    Normal                           = 0x0000
    WithDataSegs                     = 0x0001
    WithFullMemory                   = 0x0002
    WithHandleData                   = 0x0004
    FilterMemory                     = 0x0008
    ScanMemory                       = 0x0010
    WithUnloadedModules              = 0x0020
    WithIndirectlyReferencedMemory   = 0x0040
    FilterModulePaths                = 0x0080
    WithProcessThreadData            = 0x0100
    WithPrivateReadWriteMemory       = 0x0200
    WithoutOptionalData              = 0x0400
    WithFullMemoryInfo               = 0x0800
    WithThreadInfo                   = 0x1000

So, that gets me all memory, dump all threads and send to watson.  Apparently, all_memory doesn’t include the handle table.  As a test I ran SQLDumper with the flag 0x1430, with 0x1000 being maximumdump.  The full dump collected with that, got me the handle information I was looking for.

 

UPDATE 08/04/2010:

Looking at it further, you can just use 0x1400 which will give you the maximum setting along with it being sent to watson.  Here are the equivalents to doing a .dump command in the debugger (i.e. WinDBG):

SQLDumper Flag .dump /m flag
all_memory .dump /mf - Adds full memory data to the minidump. All accessible committed pages owned by the target application will be included.
maximumdump .dump /ma - Creates a minidump with all optional additions. The /ma option is equivalent to /mfFhut — it adds full memory data, handle data, unloaded module information, basic memory information, and thread time information to the minidump. Any failure to read inaccessable memory results in termination of the minidump generation.

Typically when we go for a dump outside of SQL Dumper, and it isn’t the SQL Engine, we ask for a .dump /ma to get a full dump.  There is a possibility that maximumdump could be larger than all_memory.  In fact it will be larger, but in my quick testing, it wasn’t much larger, a few meg.  But, this is dependent on the system.

 

Adam W. Saxton | Microsoft SQL Server Escalation Services
http://twitter.com/awsaxton