How (and when) does COM TreatAs work?

Question

I was looking at the registry access of vsjitdebugger.exe using Process Monitor, and I noticed that sometimes it queries the registry in the following manner (some info omited):

HKCU\Software\Classes\CLSID\{some-guid} NAME NOT FOUND  Desired Access: Read
...
HKCU\Software\Classes\CLSID\{some-guid}\TreatAs NAME NOT FOUND  Desired Access: Query Value
...
HKCU\Software\Classes\CLSID\{some-guid}\InprocServer32  NAME NOT FOUND  Desired Access: Read
...
HKCR\CLSID\{24E669E1-E90F-4595-A012-B0FD3CCC5C5A}\InprocServer32    SUCCESS Desired Access: Read

Information on TreatAs on MSDN shows that it allows specifying a GUID for another COM server which will be called instead of the original.

I wasn't able to find much more information about this key, and I wasn't able to use it on my own COM object: I have two different implementations of the same COM object (in 2 separate DLLs, having 2 separate GUIDs), and when my process creates the object via GUID, I'd like it to create the other object instead (via GUID specified in TreatAs). Unfortunately, it seems that Windows immediately tries to query HKCU\Software\Classes\CLSID\{my-guid}\InprocServer32, instead of first looking for TreatAs.

My question basically is about rules of TreatAs, when and how does it get queried?

Answer 1

TreatAs feature works pretty simple: with a request to CoCreateInstance an instance of a COM object, COM subsystem checks for TreatAs key and, when found, attempts to instantiate a substitution/emulation class and transparently return it instead of requested CLSID. The caller, thus, obtains an interface of an emulation object transparently.

The feature is rarely used, but still used. You can enumerate currently active TreatAs classes using EnumerateTreatAsClasses utility. The feature is one of the method to hook COM class instantiation.