none
Why does Office 365 Updater move Excel COM Add-ins from HKLM/Software/Microsoft/Office/Excel/Addins to HKCU and set LoadBehavior to 2? RRS feed

  • Question

  • A user called me yesterday to say that they had updated from Excel 2013 x64 to Excel 2016 x64 (Office 365) and my COM Add-in was no longer loading.

    We discovered that the upgrade process appeared to have created a single entry under HKCU/Software/Microsoft/Office/Excel/Addins/MyAddin called LoadBehavior and set the value to 2. The FriendlyName, Description, CommandLineSafe entries were not copied to this key. Just LoadBehavior.

    It left the original HKLM/Software/Microsoft/Office/Excel/Addins/MyAddin and all of the values in it like FriendlyName, Description, CommandLineSafe and LoadBehavior (3) unchanged.

    It appeared to do this for all of his COM add-ins and not just mine.

    I recall a similar incident a number of months ago when a user upgraded Excel 2010 x64 to 2013 x64. We simply deleted the HKCU/Software/Microsoft/Office/Excel/Addins/MyAddin key that the upgrade process seemed to create and all was well.

    The vast majority of my users (99%) are running the x86 version of Excel and they don't seem to be complaining so I wonder if this has something to do with it being x64.

    I'm having trouble understanding what has happened here and anticipate more calls from end users as they update to Excel 2016.

    Can anyone explain to me what might be going on?

    Thanks!

    Wednesday, September 23, 2015 5:55 PM

All replies

  • Hello,

    When users disable add-ins in the host application creates a corresponding LoadBehavior key is created in the HKCU hive for add-ins registered in the KLM. Is this the case?

    Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in when you try to debug it, the application might have hard disabled or soft disabled your VSTO Add-in.

    Hard disabling can occur when an VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.

    Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.

    When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article. 

    Wednesday, September 23, 2015 10:15 PM
  • Thanks for the response. The user did not disable the COM add-in through the COM Add-ins dialog before running the upgrade to 2016.

    The add-in's original LoadBehavior (before the upgrade) in HKLM was still set to 3 after the upgrade but Excel looks in HKCU first so saw that LoadBehavior (2) instead.

    It's also strange that LoadBehaviour is the only entry (value) underneath HKCU/Software/Microsoft/Office/Excel/Addins/MyAddin.

    I should have also mentioned in my original post the COM Add-in is built as a shared add-in and not a VSTO one.

    Wednesday, September 23, 2015 11:29 PM
  • Try to disable the add-in in Outlook run under a regular user account and you will see the HKCU key created. Outlook can't modify records in the HKLM hive due to the fact insufficient privileges. 
    Thursday, September 24, 2015 8:55 AM
  • Thanks Eugene. I guess my point is that it seems strange that the upgrade process disabled (via an entry in HKCU) all of the Excel COM add-ins. They were working before the upgrade and after the upgrade (once the HKCU LoadBehavior's had been removed).
    • Edited by Ou8 Friday, October 2, 2015 4:43 PM typo
    Thursday, September 24, 2015 2:33 PM
  • Can someone at MS confirm this behavior? Specifically, that x64 Excel COM add-in entries in HKLM/SOFTWARE/Microsoft/Office/Excel/Addins are partially copied to HKCU and LoadBehavior set to 2 (from 3).

    This doesn't seem to be happening with x86 add-ins.

    Friday, October 2, 2015 4:42 PM