Thread: Monitor the ComSubsystem

...like looking up interfaces from the registry.

I'm sure this is possible but fail to see how it is in any way useful. If you want a specific COM interface pointer then you should be using it's ID when you create the object. So if you are requesting a specific interface via the ID...why do you need to know about more IDs that are totally unrelated to your project?

The simplest way to see what is installed on your system is to add a reference to a managed project in MSVS. It will go out and find all the ActiveX and .NET objects on your system for you.

I was wondering whether there is any way to monitor what the com library is doing, like looking up interfaces from the registry. Im particulary interested in the numner of references certain com objects currently have.

Release should return the ref count for IUnknown derived types.
Why are you using COM interop to interop managed and unmanaged code? There is a much simpler way.

To call into C# from C++ you can create an unmanaged interface. The impl of the interface can use auto_gcroot<> to store managed handles. When a call comes into the unmanaged interface you can use this handle to call into the managed type which can then call into C# via a delegate or via a direct call.
http://msdn.microsoft.com/en-us/libr...48(VS.80).aspx

To call into C++ from C# create a managed ref class in managed C++. Managed ref and value classes can have native and managed members in the same class. These managed classes, in turn, can be used from C# as they are with no Pinvoke or any other nastiness. The managed class then wraps access to the unmanaged pointer and simply acts as a call through to the unmanaged code.

If you are going to be doing a lot of interop code I would recommend purchasing a book on managed C++, C#, and any books about interop between managed and unmanaged code. The cool thing about your ref classes is that any .NET language can utilize them yet the code does not have to change to work with them. You can get into trouble if you do not use pin_ptr<> when you need to: http://msdn.microsoft.com/en-us/libr...fh(VS.80).aspx.

I see that there are perfmon indicators showing the number of com-marshallings for example.

Since the marshalling is being caused by your application you should already know how much marshalling is taking place relative to your specific application.