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

Last time around, we looked at an application compatibility side-effect of User Account Control on Windows Vista: the potential impact on Mapped Network Drives when running elevated. Another side-effect that may affect application compatibility is the changes we have made around per-user COM registration.

Back in Windows NT 4.0, HKEY_CLASSES_ROOT was simply an alias of HKEY_LOCAL_MACHINESoftwareClasses. However, beginning with Windows 2000, HKEY_CLASSES_ROOT is a merged view of the data in HKEY_LOCAL_MACHINESoftwareClasses and HKEY_CURRENT_USERSoftwareClasses. Aaron Margosis discusses how to leverage this merged view (and the differences in permission) to resolve LUA bugs in his Technet article Problems of Privilege: Find and Fix LUA Bugs. You see, when we search for a COM registration, entries in the HKEY_CURRENT_USER hive take priority.

And it is exactly this property (fixing LUA bugs) that makes this load behavior dangerous if your process happens to be elevated. A standard user is able to write to these registry entries, which is why it can help applications to work. Because a standard user can write the configuration for a COM object, we don’t want to open the door to an elevation of privilege attack. If we simply enforced the same rules for an elevated process, loading entries from the user hive first, then a process could easily write a new configuration for a commonly loaded COM object, point the configuration to arbitrary code, and have an elevated process pick up that arbitrary code, executing it with administrator privileges! Consequently, we block loading of COM registrations from the per-user registry hive if the process’ integrity level is higher than medium. That means you won’t pick up a per-user COM object if you are manifested as requireAdministrator, or if you have manually elevated the application (right click – Run as Administrator). 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.

So, if you are an application developer who is designing an application to run elevated, you should make sure that you drop your COM registrations in the per-machine hive (which creating a new key in HKCR will do by default) at install time, rather than relying on a per-user installation.

Comments (8)

  1. amar1223 says:

    "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"

    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?

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

  3. cjacks says:

    Hi Amar,

    Rather than leaving this buried in comments, I addressed this in a full post here:

    Sorry about the confusion!


  4. Jerry says:

    Please help me to adress this issue when i try to run stadarad user anlyzer in a user login i am gettin this error in details of "unhandled exception elevation required"

  5. cjacks says:

    Hi Jerry,

    So we can get somebody to track down your problem, let’s get you over to a newsgroup so you have more than just me working on it. The ACT team monitors this newsgroup, so we’ll be able to get more resources helping you out.

    You can find it at

    Good luck!



  6. Thriol says:

    Using Vista SP1 and running as an Admin with UAC turned off does not work!

    The application does indeed get access to the HKCU/CLSID when using CoCreateInstance, that failed before, but you still do not get access to type libraries registered in HKCU using LoadTypeLib.

  7. cjacks says:

    Hi Thriol,

    This is known – LoadTypeLib is not in ole32.dll, it’s in oleaut32.dll. Automation is a completely different team. See