I am attempting to get handle information in kernel full memory dump by
using !handle. However I cant get it to work. I am using 6.4 and I have
tried 6.5 with the same results. The error most often is
Could not duplicate handle 94, error 6
Occasionally it would say
Could not duplicate handle f, error 87
Has anyone go this to work ? And no handle 0 does not work either. What
gives ?
I use this periodically, and have never seen the error that you are
reporting.
Of course, the contents of the handle table are process context
specific, so if you are not in a valid process context (I’m thinking
“idle process” context) then I wouldn’t expect it to return anything
useful. Since we don’t know what you are typing or the context in which
you are operating, it’s tough to suggest what might be the source of
your problems with the command.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, August 29, 2005 7:08 PM
To: Kernel Debugging Interest List
Subject: [windbg] !handle does not work
I am attempting to get handle information in kernel full memory dump by
using !handle. However I cant get it to work. I am using 6.4 and I have
tried 6.5 with the same results. The error most often is
Could not duplicate handle 94, error 6
Occasionally it would say
Could not duplicate handle f, error 87
Has anyone go this to work ? And no handle 0 does not work either. What
gives ?
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
I did a .process of course. I am in a legit process context. I
have seen it work before dumping the entire table for the process and
taking a long time. But all that good stuff is not happening anymore.
Any other ideas ?
Here is output from my session -
||9:kd> lmmnt
start end module name
80400000 805a5540 nt # (pdb symbols)
c:\websymbols\ntoskrnl.pdb\401AD8179\ntoskrnl.pdb
||9:kd> vertarget
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0
Debug session time: Sun Aug 28 01:05:42.994 2005 (GMT-7)
System Uptime: 2 days 10:21:57.103
||9:kd> .process fb0afb80
Implicit process is now fb0afb80
||9:kd> !process
PROCESS fb0afb80 SessionId: 0 Cid: 3d14 Peb: 7ffdf000 ParentCid:
03f0
DirBase: 18022000 ObjectTable: facb69e8 TableSize: 8.
Image: ping.exe
VadRoot fa43c5e8 Clone 0 Private 22. Modified 0. Locked 0.
DeviceMap 82b207a8
Token e5b1dd50
ElapsedTime 0:00:00.0010
UserTime 0:00:00.0010
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 6964
QuotaPoolUsage[NonPagedPool] 836
Working Set Sizes (now,min,max) (96, 50, 345) (384KB, 200KB,
1380KB)
PeakWorkingSetSize 96
VirtualSize 4 Mb
PeakVirtualSize 4 Mb
PageFaultCount 93
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 36
THREAD 811c3460 Cid 3d14.3c88 Teb: 7ffde000 Win32Thread:
00000000 RUNNING
||9:kd> !handle
||9:kd> !handle 0 0
||9:kd> !handle -?
!handle [handle [flags [type]]] - Dump handle information
If no handle specified, all handles are dumped.
Flags are bits indicating greater levels of detail.
If the handle is 0 or -1, all handles are scanned. If the handle is not
zero, that particular handle is examined. The flags are as follows:
1 - Get type information (default)
2 - Get basic information
4 - Get name information
8 - Get object specific info (where available)
If Type is specified, only object of that type are scanned. Type is a
standard NT type name, e.g. Event, Semaphore, etc. Case sensitive, of
course.
Examples:
!handle – dumps the types of all the handles, and a summary
table
!handle 0 0 – dumps a summary table of all the open handles
!handle 0 f – dumps everything we can find about a handle.
!handle 0 f Event
– dumps everything we can find about open events
||9:kd> !handle 0 f
||9:kd> !handle 0 f Event
||9:kd> ||.
. 9 32-bit Full kernel dump: \memory.dmp
.process doesn’t change the context for extension commands, but it looks
like that’s your context anyway.
Confirm that the object handle table is visible (!pte facb69e8 should do
it for example, or “dd facb69e8” would do it as well).
I’ve seen cases where sections that should be in the dump are missing,
and that can cause some funky results. Combine that with the debugger’s
penchant for trapping exceptions and you may very well just have some
missing memory in this instance.
Is this problem specific to a particular dump, or are you seeing this in
some broader sense?
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, August 29, 2005 8:44 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] !handle does not work
Here is output from my session -
||9:kd> lmmnt
start end module name
80400000 805a5540 nt # (pdb symbols)
c:\websymbols\ntoskrnl.pdb\401AD8179\ntoskrnl.pdb
||9:kd> vertarget
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0
Debug session time: Sun Aug 28 01:05:42.994 2005 (GMT-7)
System Uptime: 2 days 10:21:57.103
||9:kd> .process fb0afb80
Implicit process is now fb0afb80
||9:kd> !process
PROCESS fb0afb80 SessionId: 0 Cid: 3d14 Peb: 7ffdf000 ParentCid:
03f0
DirBase: 18022000 ObjectTable: facb69e8 TableSize: 8.
Image: ping.exe
VadRoot fa43c5e8 Clone 0 Private 22. Modified 0. Locked 0.
DeviceMap 82b207a8
Token e5b1dd50
ElapsedTime 0:00:00.0010
UserTime 0:00:00.0010
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 6964
QuotaPoolUsage[NonPagedPool] 836
Working Set Sizes (now,min,max) (96, 50, 345) (384KB, 200KB,
1380KB)
PeakWorkingSetSize 96
VirtualSize 4 Mb
PeakVirtualSize 4 Mb
PageFaultCount 93
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 36
THREAD 811c3460 Cid 3d14.3c88 Teb: 7ffde000 Win32Thread:
00000000 RUNNING
||9:kd> !handle
||9:kd> !handle 0 0
||9:kd> !handle -?
!handle [handle [flags [type]]] - Dump handle information
If no handle specified, all handles are dumped.
Flags are bits indicating greater levels of detail.
If the handle is 0 or -1, all handles are scanned. If the handle is not
zero, that particular handle is examined. The flags are as follows:
1 - Get type information (default)
2 - Get basic information
4 - Get name information
8 - Get object specific info (where available)
If Type is specified, only object of that type are scanned. Type is a
standard NT type name, e.g. Event, Semaphore, etc. Case sensitive, of
course.
Examples:
!handle – dumps the types of all the handles, and a summary
table
!handle 0 0 – dumps a summary table of all the open handles
!handle 0 f – dumps everything we can find about a handle.
!handle 0 f Event
– dumps everything we can find about open events
||9:kd> !handle 0 f
||9:kd> !handle 0 f Event
||9:kd> ||.
. 9 32-bit Full kernel dump: \memory.dmp
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Also, the output looks like you may be using ntsdexts extension dll
against a kernel session. Can you confirm from .chain that this is not
the case?
Jason
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, August 29, 2005 6:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] !handle does not work
.process doesn’t change the context for extension commands, but it looks
like that’s your context anyway.
Confirm that the object handle table is visible (!pte facb69e8 should do
it for example, or “dd facb69e8” would do it as well).
I’ve seen cases where sections that should be in the dump are missing,
and that can cause some funky results. Combine that with the debugger’s
penchant for trapping exceptions and you may very well just have some
missing memory in this instance.
Is this problem specific to a particular dump, or are you seeing this in
some broader sense?
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, August 29, 2005 8:44 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] !handle does not work
Here is output from my session -
||9:kd> lmmnt
start end module name
80400000 805a5540 nt # (pdb symbols)
c:\websymbols\ntoskrnl.pdb\401AD8179\ntoskrnl.pdb
||9:kd> vertarget
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0
Debug session time: Sun Aug 28 01:05:42.994 2005 (GMT-7)
System Uptime: 2 days 10:21:57.103
||9:kd> .process fb0afb80
Implicit process is now fb0afb80
||9:kd> !process
PROCESS fb0afb80 SessionId: 0 Cid: 3d14 Peb: 7ffdf000 ParentCid:
03f0
DirBase: 18022000 ObjectTable: facb69e8 TableSize: 8.
Image: ping.exe
VadRoot fa43c5e8 Clone 0 Private 22. Modified 0. Locked 0.
DeviceMap 82b207a8
Token e5b1dd50
ElapsedTime 0:00:00.0010
UserTime 0:00:00.0010
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 6964
QuotaPoolUsage[NonPagedPool] 836
Working Set Sizes (now,min,max) (96, 50, 345) (384KB, 200KB,
1380KB)
PeakWorkingSetSize 96
VirtualSize 4 Mb
PeakVirtualSize 4 Mb
PageFaultCount 93
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 36
THREAD 811c3460 Cid 3d14.3c88 Teb: 7ffde000 Win32Thread:
00000000 RUNNING
||9:kd> !handle
||9:kd> !handle 0 0
||9:kd> !handle -?
!handle [handle [flags [type]]] - Dump handle information
If no handle specified, all handles are dumped.
Flags are bits indicating greater levels of detail.
If the handle is 0 or -1, all handles are scanned. If the handle is not
zero, that particular handle is examined. The flags are as follows:
1 - Get type information (default)
2 - Get basic information
4 - Get name information
8 - Get object specific info (where available)
If Type is specified, only object of that type are scanned. Type is a
standard NT type name, e.g. Event, Semaphore, etc. Case sensitive, of
course.
Examples:
!handle – dumps the types of all the handles, and a summary
table
!handle 0 0 – dumps a summary table of all the open handles
!handle 0 f – dumps everything we can find about a handle.
!handle 0 f Event
– dumps everything we can find about open events
||9:kd> !handle 0 f
||9:kd> !handle 0 f Event
||9:kd> ||.
. 9 32-bit Full kernel dump: \memory.dmp
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
>Also, the output looks like you may be using ntsdexts extension dll
against a kernel session. Can you confirm from .chain that this is not
the case?
That’s it. Was it because one of the dumps that was under analysis was a
user mode dump ? How do I prevent this from happening in future. I got
it to work by
!kdextx86.handle 0 0
processor number 0
PROCESS fb0afb80 SessionId: 0 Cid: 3d14 Peb: 7ffdf000 ParentCid:
03f0
DirBase: 18022000 ObjectTable: facb69e8 TableSize: 8.
Image: ping.exe
Handle Table at e4f0d000 with 8 Entries in use
004c: Object: fa426228 GrantedAccess: 00100020 (Inherit)
0058: Object: 81ec8348 GrantedAccess: 00120196 (Inherit)
Things that I am used to seeing. Thanks a lot !!
Satya
>.process doesn’t change the context for extension commands, but it
looks like that’s your context anyway.
That is the command I use to switch to process context. I know for
titanium, one should use .context instead. What do you use ?
Is this problem specific to a particular dump, or are you seeing this
in some broader sense?
I was seeing this in multiple dumps. Of course I had forgotten about the
fact that one of them was a user dump.
That’ll do it. If you’re using .opendump to debug multiple dumps at a
time, the debugger can indeed get into a state where commands you type
will go to the wrong extension versions. This applies to both
umode->kmode, and also different OS types (extensions in w2kfre and
winxp directory, for example).
Unfortunately, the extension searching isn’t smart, so you’ll have to be
careful and specify exactly which extension you want to use (as you did
below). I would guess that a ‘.restart’ may reset your extensions to a
good state, but I don’t have enough multi-dump-debugging experience to
say for sure.
Jason
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, August 29, 2005 6:28 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] !handle does not work
Also, the output looks like you may be using ntsdexts extension dll
against a kernel session. Can you confirm from .chain that this is not
the case?
That’s it. Was it because one of the dumps that was under analysis was a
user mode dump ? How do I prevent this from happening in future. I got
it to work by
!kdextx86.handle 0 0
processor number 0
PROCESS fb0afb80 SessionId: 0 Cid: 3d14 Peb: 7ffdf000 ParentCid:
03f0
DirBase: 18022000 ObjectTable: facb69e8 TableSize: 8.
Image: ping.exe
Handle Table at e4f0d000 with 8 Entries in use
004c: Object: fa426228 GrantedAccess: 00100020 (Inherit)
0058: Object: 81ec8348 GrantedAccess: 00120196 (Inherit)
Things that I am used to seeing. Thanks a lot !!
Satya
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com