Instantiating a COM Component fails with "Class not registered" when "Run As Administrator"

10,813

You registered the object for your local user account without administrative privileges, instead of doing so from an administrative process. Because of that, the COM component is registered under the user-specific area of the registry (as you yourself indicated: HKC*U* ).

When a process runs without administrative privileges, it is presented with a merged view of the HKCR registry, which includes all the HKCU\Software\Classes entries plus anything in HKLM\Software\Classes that hasn't been overridden in HKCU\Software\Classes. When a process runs as administrator, the registry only shows the HKLM\Software\Classes entries.

See this link for more details: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724498(v=vs.85).aspx

The weird thing is, RegSvr32 won't register under the HKCU\Classes key. If you run it without administrative rights, it will just fail (just checked to make sure, in Windows 7). How was the COM component registered?

Share:
10,813
Matt Smith
Author by

Matt Smith

Software Developer @ Autodesk [email protected]

Updated on June 04, 2022

Comments

  • Matt Smith
    Matt Smith almost 2 years

    When instantiating a COM Interop object:

    var comObj = new ComComponentClass();
    

    I get the COMException:

    Retrieving the COM class factory for component with CLSID 
    {C343ED84-A129-11D3-B799-0060B0F159EF} failed due to the following error: 
    80040154 Class not registered 
    (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
    

    I only get this error when I launch my application with Run as Administrator. When I run normally, the error does not occur.

    Notes:

    • The application is 64-bit application.
    • The COM component is an inproc server in a 64-bit dll.

    Any ideas as to where I should start investigating why this difference occurs?

    What I've tried:

    I've used Procmon to watch what registry keys it inspects.

    • In both cases, the appropriate dll is located by inspecting the key HKCU\Software\Classes\CLSID\{C343ED84-A129-11d3-B799-0060B0F159EF}\InprocServer32
    • In both cases it queries the key HKCR\CLSID\{C343ED84-A129-11D3-B799-0060B0F159EF} and gets back NAME NOT FOUND. Which I find strange (since I can find that key using regedit.exe. But since this doesn't differ between the two scenarios, it didn't seem important.
  • Christian Hayter
    Christian Hayter about 11 years
    My guess would be: he installed it from an MSI, and selected the "install only for this user" option.
  • Matt Smith
    Matt Smith about 11 years
    An installer installed it, but there wasn't an "install only for this user" option. So next steps is to figure out how it got registered. Many thanks for the explanation.