views:

404

answers:

4

I am looking for a way to locate all current instances on the heap of types that implement a given interface (during WinDbg debugging that is). As interfaces are not types in the sense that you can create instances of an interface, they obviously do not show up when inspecting the heap. I.e. !dumpheap is of little help here.

However, !dumpmt -md on a given MT lists the number of IFaces in IFaceMap. As far as I can tell this number seems to indicate if the type implements one or more interfaces or not. When using the -md flag methods on the type are also listed.

Unfortunately the !dumpmd doesn't tie a given method to an interface as far as I can tell, so this cannot be used to establish the implemented interfaces.

I assume this information is available somewhere in memory, but I am not sure where to look. Any input is highly appreciated.

A: 

If you don't have to create your own program, try NDepend.

dipbhi
I can't see how NDepend would be useful here. I have all the source code available, so I can find implementers if needed. I am interested in finding instances in memory at runtime.
Brian Rasmussen
A: 

Have you tried

!dumpheap -type IFaces

It will show the method tables too. You can dig deeper from there.

Dominic Zukiewicz
No, that lists instances of types for which IFaces is part of their name. The type parameter uses a regular text match on type names and thus has nothing to do with interfaces.
Brian Rasmussen
A: 

Your best bet would be to start with Crack.NET, which does some of what you want to do (although it targets wpf and winforms apps). The project is open source so you should be able to derive the method used to get the information you want from the source. It has a plugin that for Reflector that allows you to inspect the details of an in memory object as well.

Project page: http://joshsmithonwpf.wordpress.com/cracknet/

CodePlex: http://cracknetproject.codeplex.com/

free-dom
+1  A: 

A few years ago, I was desperate for some information like this. I ended up creating a treeview that would only appear when you used an obscure option for starting the app. When I clicked "refresh", it would use reflection to travel through all the properties of the root class instance. If it found a property that was a collection or held other properties, it would recursively call into them. The end result was that a tree of the instance data at that point was available for perusal.

The main points to this approach are

  1. Make sure you have only one top-level object instance, or you know exactly how many and which top-level instances there are. (Also, don't forget about static values.)
  2. Figure out how to use reflection to look through the relevant bits of information.
  3. Display it when needed and in a readable fashion.
John Fisher
Well, the information is available in the source code. I would just like to find out how to dig out the info during debugging. Since the runtime must have this information somewhere it is "just" a matter of digging out the details. But thanks for your input anyway.
Brian Rasmussen