Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1

A while back, I was talking about per-user COM registration and elevated processes on Windows Vista.

True at the time was this fact:

It also means you won’t pick up a per-user COM object if you are running as a member of the local Administrators group and you have disabled UAC for some reason.

And somebody dug this up and pointed out that this no loner appears to be true:

Doesn’t seem to follow this after updating to SP1.

On my Vista Business SP1, running as an admin with UAC disabled, my program picks up COM registered to HKCU.

This was working fine – as described before installing SP1.

Is this intentional?

Yes, it is intentional – we changed the behavior. Having it behave this way was actively preventing people from using per-user COM, because there was a scenario (UAC disabled) where it would never ever work.

So, the behavior beginning with Windows Vista SP1 for per user COM registration is:

UAC Disabled – You see per-user COM classes

UAC Enabled – Not Elevated – You see per-user COM classes

UAC Enabled – Elevated – You do not see per-user COM classes

We believe that per-user COM registration has value, but developers are certainly not going to use this approach if it will never work on some percentage of desktops, no matter how small that percentage is (currently hovering at around 12% – but on the scale of Windows that’s pretty huge). So we made that change. However, on machines with UAC enabled, we will help keep you more secure by continuing to prevent a standard user from injecting something into an elevated process using this mechanism.

Updated 16-June-2008: Aaron pointed out that I was overpromising to “keep you secure” and requested that I soften the statement a bit. Fixed it to be a touch less loosey-goosey.

Comments (5)

  1. Dan G. says:

    I’m not sure your post post relates to a problem I’m seeing and trying to understand.

    I use the RegOverridePredefKey API to spy on a COM binary to see what entries it makes when it registers itself.  I then print out those entries to an .rgs file in which any entries which the binary would have made to HKCR or HKLM get shunted to HKCUSoftwareClasses.

    This all works fine on windows XP.  But I find when I run mytool on Vista, some of the .rgs files I get back are missing whole sections from an identical run on an XP machine.

    Specifically, I see that Typelib and Interface entries are being omitted.  Is there any reason why this should happen on Vista? I’m running the tool as administrator (right click on cmd.exe and choose run as admin).  The registry where I divert the written keys to also has no record of the missing Interface/Typelib entries.

  2. Bob says:

    we are also seeing the same RegOverridePredefKey issue on Vista64 with TLBs and interfaces. Are you using  ATL? What version? I think I’ve narrowed it down to somewhere in there, but not sure yet.

  3. Hims says:

    This is not working. We have a per-user application, for which we register a local COM server under HKCU. While an out-of-proc client in Vista SP1 is able to CoCreate the local COM server just fine, marshaling an interface does not work. Using ProcMon, it appears that the COM marshaler is looking for the interface registration, ProxyStubClsid32, under HKLM instead of HKCU.

    Any workaround for this? Also, what can we can do about Vista RTM, where HKCU registration does not work at all? Other than registering under HKLM that is.

  4. cjacks says:

    Hi Hims,

    What code are you running specifically when it fails?

    On Vista RTM, you only run into an issue with HKCU when you run elevated – the solution is to not use HKCU registration in an app designed to run elevated. I know you can’t stop the user from disabling UAC if they are an admin, but that’s why we changed it for SP1.



  5. Here’s an interesting lesson which, quite honestly, I haven’t thought about for a while. But it turns