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
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.
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
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.
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):
.dump /m flag
.dump /mf - Adds full memory data to the minidump. All accessible committed pages owned by the target application will be included.
.dump /ma - Creates a minidump with all optional additions. The
option is equivalent to
— 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.