Finding and reading handle tables

Evgeny,

We don't currently have a way to do this. Up to now, I guess no one has really felt a need for this capability, so I'm curious to know exactly what you were wanting to do this for

BTW, you can get an updated version of the debugger tools for 1.1 from http://www.microsoft.com/whdc/devtools/debugging/default.mspx and I believe it may have the GCHandleLeaks command.

Thanks,

Diane

Evgeny,

Can you help us understand the big-picture problem you're trying to solve At best there may be other approaches for solving it, and if not we'll have a better idea of how we might address this in the future.

Thanks,
Jon

Evgeny,

Actually, you've put your finger on the problem exactly. It's a simple enough matter to get the start of each handle table. !GCHandles will give you that. What's not available is where the end of the table is. In fact, it's possible that part of a particular handle table may not even be mapped at a particular point in execution. That more or less precludes being able to do anything like reading consecutive values until you hit something that no longer looks like a handle (i.e., not NULL and the referent lies within the heap segments, which are available via the !eeheap -gc command).

You're right that the time that !GCHandleLeaks takes is mostly due to searching for the references in memory. Thus, the !GCHandles command would be better suited to your purposes, except it doesn't actually print the handles, it just counts them. This is something we've never had any demand for (until now :-)). It would be interesting to know if others would find this useful too.

I'm still curious why you're wanting to know what objects are being kept alive specifically by handles. Is this part of a larger task of finding all live objects The output here could be tremendously large, so it might not be the most useful information to provide.

Diane

Evgeny,

The starting addresses for the handle tables are at the beginning of the output from !GCHandles (I used the debugging tools downloaded from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx). The output from 2.0 is similar. In this case, we have three tables.

0:000> !GCHandles
Loaded Son of Strike data table version 5 from "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\mscorsvr.dll"
Scan HandleTable 0x148c90
Scan HandleTable 0x14d9e8
Scan HandleTable 0x1c8fb0

Unfortunately, we don't have a way to give you the end of the tables (although they do have an end, as you suppose!). If you try to read an unmapped address, you'll AV, so I wouldn't advise trying to traverse them blindly.

So correct me where I'm misinterpreting you. It sounds like perhaps you're planning to save time getting the information that !GCRoot gives by doing some kind of pre-analysis of the dump file. Is that correct What exactly do you plan to store that will make this more efficient What kind of analysis do you mean to do I'm asking, because I'm having trouble understanding how you'll be able to speed things up.

Thanks,
Diane

Evgeny,

Believe me, I'm not trying to get you to "make a fool of yourself!" :-) If that's enough to get you started, maybe you can do enough initial proof-of-concept work to determine whether you want to pursue this further. If you need more help, please post back to this thread.

Diane