interpretetation of !GCRoot

Discussion:

(too old to reply)

coredumper

2006-01-06 06:03:02 UTC

Hi,

I'm in the midst of trying to track a nasty interop bug and am using the SOS
extension to WinDbg. My question is: How do I interpret some of the
information from the !GCRoot command. Here is an object that I expected to
be finalized, and my output:

0:034> !GCRoot 07224988
Scan Thread 0 (1774)
Scan Thread 10 (b14)
Scan Thread 14 (16ec)
Scan Thread 15 (1a58)
Scan Thread 20 (ee8)
Scan Thread 6 (2154)
Scan Thread 11 (2ed8)
Scan Thread 27 (1c9c)
Scan Thread 34 (191c)
Scan HandleTable 16cf28
Scan HandleTable 17d240
HANDLE(RefCnt):30212b0:Root:07224988(GE.CPO.Registration.UI.Registration)

If believe this indicates that some unmanaged code is holding onto a COM
pointer to my managed object. How can I take this a step further and figure
out who?

Sorry if this is not appropriate for this group,

thanks,

-Frank

Drew Bliss [MSFT]

2006-01-06 22:09:41 UTC

Permalink

I couldn't get a direct description, but the suggestion was to use
!GCHandleLeaks.

!GCHandleLeaks
This command is an aid in tracking down GCHandle leaks. It searches all of
memory for any references to the Strong and Pinned GCHandles in the process,
and reports what it found. If a handle is found, you'll see the address of
the reference. This might be a stack address or a field within an object,
for example. If a handle is not found in memory, you'll get notification of
that too.
The command has diagnostic output which doesn't need to be repeated here.
One thing to keep in mind is that anytime you search all of memory for a
value, you can get false positives because even though the value was found,
it might be garbage in that no code knows about the address. You can also
get false negatives because a user is free to pass that GCHandle to
unmanaged code that might store the handle in a strange way (shifting bits,
for example).
For example, a GCHandle valuetype is stored on the stack with the low bit
set if it points to a Pinned handle. So !GCHandleLeaks ignores the low bit
in it's searches.
That said, if a serious leak is going on, you'll get a ever-growing set of
handle addresses that couldn't be found.

Post by coredumper
Hi,
I'm in the midst of trying to track a nasty interop bug and am using the SOS
extension to WinDbg. My question is: How do I interpret some of the
information from the !GCRoot command. Here is an object that I expected to
0:034> !GCRoot 07224988
Scan Thread 0 (1774)
Scan Thread 10 (b14)
Scan Thread 14 (16ec)
Scan Thread 15 (1a58)
Scan Thread 20 (ee8)
Scan Thread 6 (2154)
Scan Thread 11 (2ed8)
Scan Thread 27 (1c9c)
Scan Thread 34 (191c)
Scan HandleTable 16cf28
Scan HandleTable 17d240
HANDLE(RefCnt):30212b0:Root:07224988(GE.CPO.Registration.UI.Registration)
If believe this indicates that some unmanaged code is holding onto a COM
pointer to my managed object. How can I take this a step further and figure
out who?
Sorry if this is not appropriate for this group,
thanks,
-Frank

coredumper

2006-01-06 23:31:01 UTC

Permalink

Thanks Drew,

This is very useful. I found I was running a n old version of SOS that did
not have the additional commands like !GCHandleLeaks

Post by Drew Bliss [MSFT]
I couldn't get a direct description, but the suggestion was to use
!GCHandleLeaks.
!GCHandleLeaks
This command is an aid in tracking down GCHandle leaks. It searches all of
memory for any references to the Strong and Pinned GCHandles in the process,
and reports what it found. If a handle is found, you'll see the address of
the reference. This might be a stack address or a field within an object,
for example. If a handle is not found in memory, you'll get notification of
that too.
The command has diagnostic output which doesn't need to be repeated here.
One thing to keep in mind is that anytime you search all of memory for a
value, you can get false positives because even though the value was found,
it might be garbage in that no code knows about the address. You can also
get false negatives because a user is free to pass that GCHandle to
unmanaged code that might store the handle in a strange way (shifting bits,
for example).
For example, a GCHandle valuetype is stored on the stack with the low bit
set if it points to a Pinned handle. So !GCHandleLeaks ignores the low bit
in it's searches.
That said, if a serious leak is going on, you'll get a ever-growing set of
handle addresses that couldn't be found.