Per-user COM in Vista (where CLSIDs, etc. go under HKCU\Software\Classes instead of HKLM\Software\Classes) behaves different on Vista compared to XP. Actually it does not work at all for full administrators (to be precise, it is actually for any process with a MIC level higher than medium but more on that later). The CoCreateInstance or CreateObject call will return 0x800A01AD (-2148139437 or “server can’t create object” or REGDB_E_CLASSNOTREG).
The reason that it is not working is – you guessed it – a security issue. Non-elevated administrators are standard users and they can write to HKCU and hence \Software\Classes to their hearts content. So it would allow them to add entries to the registry that a process running under a full administrator token then would read.
Imagine the scenario where a rogue COM component is registered under HKCU by a non-elevated administrator process. There is no need for a consent dialog since again, standard users can write to HKCU. When a program is running as full administrator it could load the rogue COM dll under its all too powerful admin token in its process space. This is a schoolbook example of elevation of privilege. It is also going against the basic premise of UAC that anything running on the machine as administrator has to be installed and approved by an administrator.
Thanks Saji and Riyaz for helping me on this.