First published on MSDN on Aug 04, 2010
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:tempSQLDmpr0001.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 FilesMicrosoft SQL Server100Shared>sqldumper /?
Usage: sqldumper [ProcessID [ThreadId [Flags[:MiniDumpFlags] [SqlInfoPtr [DumpDir [ExceptionRecordPtr [ContextPtr [ExtraFile]]]]]]]] [-I<InstanceName>] [-S<ServiceName>][-remoteservers:[print|dump|freeze|resume|remote:guiddumporiginsignaturelocalIdportoperationType]]
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
https://twitter.com/awsaxton
