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 = 0x8000MiniDumpFlags:
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.
Adam W. Saxton | Microsoft SQL Server Escalation Services
http://twitter.com/awsaxton