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.