Troubleshooting Outlook COM Addins – Using ProcMon

  • Article

As I explained in my first post, Office uses the ProgId found in the office specific Addin registry (\Software\Microsoft\Office\Outlook\Addins\) to activate the COM component.  Calling CoCreateInstance kicks off a series of COM calls which you can see the results of using Process Monitor (ProcMon).  ProcMon can be downloaded here technet.microsoft.com/en-us/sysinternals/default.aspx or if you have Windows Vista you can just run the following command: Start > Run > [\\live.sysinternals.com\tools\](file://\\live.sysinternals.com\tools\). Which I think is super cool, but I digress.

Once you have ProcMon up and running I would suggest narrowing the output to a specific application.  ProcMon captures a ton of data so you want to be sure that you only get the data necessary to solve the problem.  To filter on a specific application, go to Filter > Filter….  Next choose ‘Process Name’ from the first drop down and type in Outlook.exe in the Edit Box to it’s left, then click Add.

ProcMon_Filter

Now go back to the registry and confirm that the LoadBehavior or your Addin is 0x3.  This will cause Outlook to load the Addin at Startup and should call your OnConnection implementation.  Next, make sure you are actually capturing data in ProcMon and start Outlook.  You should see a good amount of data.  Once Outlook is up and running and you still don’t see your Addin loaded (by whatever mechanism you use), stop the ProcMon from capturing data.  If you are like me, I hate to use the mouse so I just do CTRL+E on the keyboard.

When analyzing data from a ProcMon I do the following:

  1. Confirm that Outlook is finding my component.  I look at the section of the trace where Outlook looks at it's Addin registry under \Software\Microsoft\Office\Outlook\Addin.  Remember that that Addin registry is in two hives HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER so there may be two places within the trace containing this data.  If I see any ACCESS DENIED’s or NOT FOUND entries I know that Outlook doesn’t know about my Addin, and therefore isn’t going to load it.
  2. Confirm that COM is finding my component.  I focus my attention of the section of the trace that looks at the HKCR\<ProgId> or HKCU\<ProgId> and see if there are any ACCESS DENIED's or NOT FOUND entries.  If you see any of these entries than you know that your Addin is not properly registered.
  3. Continue to dig deeper into the COM registry.  Most of the time the problem surfaces by step 2.  However, if I want to verify that the component is registered correctly I will look at HKCR\CLSID\<CLSID>, HKCR\TypeLib or HKCR\Interface.  The last two I have never ever ever had a problem with, but just to cover my bases.

Both of these lend themselves to a problem with the registration (Addin or COM) of the Addin on the machine.  This could be in the installer program or the Addin itself.  COM components should be self-registering so to eliminate the Addin as a problem, just register the Addin manually*.  If the Addin is unmanaged, the following command will work:

regsvr32.exe <path to dll>

If the Addin is a managed Shared COM Addin, the following command will work:

regasm.exe <path to dll> /codebase

For some reason the codebase switch is required.

Once you have done that, go back to the Addin registry and confirm that the LoadBehavior is 0x3.  Then restart Outlook.

* Note – This does not apply to VSTO solutions.  VSTO solutions must be installed via an Installer.  You will have to set up those keys manually and that discussion is out of the scope of this series.