The first tool extension for SAD is about COM.
When you need to call COM objects methods from .NET code, the runtime creates for you R(untime) C(allable) W(rappers) to hide all the complexity behind this kind of communication and lifetime management. On the opposite, when your native code calls methods from .NET components presented as COM objects, the runtime also creates kind of proxy objects named C(om) C(allable) W(rappers).
In both case, you might need to ensure that your code handle the lifetime of such wrappers the right way (maybe playing with ReleaseComObject sometimes). To sum up, you need to know which COM objects are still refusing to self-release behind a RCW or how instances of .NET types are still referenced by CCWs. This is exactly what the « COM Analysis » tool does in SAD.
When you click this menu, a new window appears that parses the output result of sos!syncblk -all.
At the end of the analysis, the identified RCWs and CCWs are listed. If you click on a RCW line, you get a dump of the first addresses in the vtable of the corresponding COM object. Since the version 4.0 of the runtime, you always see __ComObject instead of the generated proxy class with a name that could help you figure out which COM object has been instanciated. As you can see,
you still get the vtable details even for__ComObject.
Note that you should have setup the symbols for your COM objects if you want to see meaningful names instead of just the name of the DLL where the COM objects are implemented.
The CCW case is even simpler since the type name and the reference of the .NET instance wrapped by a CCW appears in the right handside of the line
- COM Wrappers
- Runtime Callable Wrappers
- COM Callable Wrapper
- Getting IUnknown from __ComObject
- Runtime Callable Wrapper Internals and common pitfalls
I hope this helps.