The fact that you have to register a component category (which you can do programmatically when regasm.exe is called on your assembly; read about the ComRegisterFunctionAttribute and ComUnregisterFunctionAttribute classes in the .NET Framework - which run in addition to the normal registration) means that some COM client is going to use ICatInformation::EnumClassesOfCategories (or equivalent) to get COM servers implementing supported interfaces. Your DLL is one such COM server. The MSAS is a COM server that is actually querying for this information about implementations such as your state service. BTW - you should not be installing your files into the system directory. Since your using regasm.exe you can install them anyway (but keep them there), or - better yet (recommended) sign the assembly (more secure anyway) and install it into the GAC using gacutil.exe and then use regasm.exe MSASState.dll (no /codebase, which tells the mscoree.dll shim to look in the GAC). It's your job as the developer of this sink to communicate your data to whatever client you want. With .NET, your best approach is to use .NET Remoting. If you haven't already, read Retrieving Media Status[^] in the SDK that explains how the MSAS loads the sinks (your assembly, acting as a COM server indirectly through the mscoree.dll shim). And creating a Windows Forms application that references this assembly won't do any good - you need to reference the object that MSAS has loaded. This is where .NET Remoting comes in. You need to communicate this data between the AppDomain that was created for your sink and the AppDomain for your Windows Forms application (using statis will not work - each AppDomain is a separate context). Read the .NET Remoting Overview[^]. There's also several good articles on this site about .NET Remoting, as well as a couple good books like "Microsoft .NET Remoting" from Microsoft Press[