How to troubleshoot the COM Add-ins loading issues

1.         What is the unmanaged COM Add-ins loading process?

Here is a COM Add-in registry example.



"Description"="Composed in ATL 8.0"


         HKEY_CURRENT_USER: this is user level COM-Addin

         Excel: This is an Excel COM Addin

         UnmanagedAddin.Connect: This is progid of the COM Add-in

         LoadBehavior: control how the Add-in will be loaded.

         You may refer the link below about LoadBehavior


a)        Check the registry for the available COM Add-ins





HKEY_CURRENT_USER one: stored the COM Add-ins for the current user only. (i.e. when we installed the Add-in, we checked “just for me”, user level)

HKEY_LOCAL_MACHINE one: stored the COM Add-ins for all users. (i.e. when we installed the Add-in, we checked “Everyone”, machine level) 

b)        Found an entry of Add-in (UnmanagedAddin.Connect) of LoadBehavior 3.

c)         Attempt to locate the COM DLL of progid “UnmanagedAddin.Connect”(Common COM Load procedure)

                        i.              Found HKEY_CLASSES_ROOT\UnmanagedAddin.Connect\CurVer

Default Value is “UnmanagedAddin.Connect.1"

                      ii.              Found “HKEY_CLASSES_ROOT\UnmanagedAddin.Connect.1\CLSID”

Default Value is “{F51126A7-472D-4D3D-A011-8D1467F6BAFD}”

                    iii.              Located the registry key below.



@="Connect Class"


@="c:\\users\\username\\documents\\visual studio 2005\\projects\\comaddins\\unmanagedaddin\\debug\\UnmanagedAddin.dll"









                     iv.              Loaded the DLL with Win32 LoadLibrary API.


2.         What is the managed COM Add-ins loading process?

a)        The steps are similar except for step 1 c) iii



[HKEY_CLASSES_ROOT\CLSID\{5E5E6110-C49E-41FD-891B-7693500F0EC4}\Implemented Categories]

[HKEY_CLASSES_ROOT\CLSID\{5E5E6110-C49E-41FD-891B-7693500F0EC4}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]





"Assembly"="ManagedAddin, Version=1.0.2552.27634, Culture=neutral, PublicKeyToken=null"


"CodeBase"="file:///C:/Users/username/Documents/Visual Studio 2005/Projects/COMAddins/ManagedAddin/bin/Debug/ManagedAddin.dll"


b)        In a managed scenario, the mscoree.dll will be loaded instead of the Add-in DLL directly. Then, it is the mscoree.dll which loads the managed Add-in DLL.


3.         General troubleshooting steps are based on the COM Add-ins Load Process.

a)        Disable all the other COM Add-ins and restart Office Product

b)        Go through the COM Add-in Load Procedure.

                        i.              If the registry key existed (refer to 1 a)), did the LoadBehavior set to 3?

                      ii.              Follow the steps that how COM DLL is Loaded (refer to 1 c))


4.         Some general approaches.


a)        By default the .NET CAS (Code Access Security) setting is OK for COM Add-ins, but this is a new security check added by .NET. When you develop managed COM Add-ins, you may try to add “Full Trust” permission set for the Add-in DLL when you have no idea.


b)        Embrace your code in a “try…catch” block and write Log when error occurred.


c)         Isolate the problem.

Comment out all of your code, and put the simple code as below in your OnConnect method. Once this is called, we should consider the Add-in loading to be OK.


STDMETHODIMP CConnect::OnConnection(IDispatch *pApplication, AddInDesignerObjects::ext_ConnectMode /*ConnectMode*/, IDispatch *pAddInInst, SAFEARRAY ** /*custom*/ )


        ::MessageBoxW(NULL,L"Hello",L"Test Dialog",MB_ICONINFORMATION);

        return S_OK;


d)        Leverage the tools Filemon/Regmon to track the registry/file security setting.



Comments (4)

  1. ca0v says:

    Does Office do any logging to explain why it changes the LoadBehavior from 3 to 2?

  2. Jim Black CG says:

    I have a puzzling situation on Vista with a COM Addin not being able to find my Addin’s COM type even though the registry entries seem to be there.  My customer is repeatedly seeing LoadBehavior go from 3 to 2 when he attempts to connect to the Addin, so I wrote a diagnostic program for him to run.   The diagnostic program runs independently of Office to see if it can load my Add-In.  First it walks thru the registry and reports that it finds all registry keys/values that are required:

    1) HKCU/./MSProject/Addins/ProgID.Connect

    2) HKCU/Software/Classes/ProgID.Connect/CLSID

    3) HKCU/Software/Classes/CLSID/{B3A3…}/InprocServer/(default)

    It reports that it finds all of these and that all have their expected values.

    It tries to load the the addin with the call CreateObject("ProgID.Connect").   This fails with a generic error message ("cannot load ActiveX component").

    Then it tries to look up the COM type associated with my Addin so that it can attempt to load the addin with CreateInstance(myCOMType).   When it executes myCOMType= Type.GetTypeFromProgID("ProgID.Connect"), it return a null reference.   What’s going on here? Why can’t Type.GetTypeFromProgID find a ProgID that’s clearly in the registry?

Skip to main content