Windows  ·  medium  ·  Microsoft Office

An add-in keeps disabling itself, or will not stay enabled

An add-in is re-enabled, works for a session, and is off again the next morning. Office has a resiliency mechanism that disables anything it believes caused a crash or a slow start, and it keeps its own list that ticking the box does not clear.

What you see

"A problem was detected with the X add-in. It has been disabled." Re-enabling it through the Add-ins dialog works until the next restart. In some cases the add-in is simply absent from the ribbon with no message at all.

What is actually wrong

Office maintains a hard-disabled list and a crashing-add-in list per application under Resiliency. An add-in that crashed once, or that took too long to load, is added to one of them and disabled on every subsequent start regardless of the LoadBehavior setting. Slow loading is measured against a threshold, so a machine that is under load or on a slow disk can disable a perfectly healthy add-in.

Codes and articles

add-in has been disabledDisabledItemsCrashingAddinListLoadBehaviorDoNotDisableAddinList

Start here — find out which fix applies

A script that runs the 4 inspection commands from the write-up below and prints what each one returned. It reads the machine and changes nothing — every command that could write, delete, start or stop is excluded from it by construction. Run this first, then pick the fix its output points at.

Download the read-only diagnosticchanges nothing · safe to run before reading

Fixes (3)

Clear the resiliency lists
PowerShell as the affected user20 minuteslow riskreversible

The add-in reports that it was disabled because of a problem, or re-enabling it does not survive a restart.

  1. Close every Office application first. These keys are read at startup and rewritten at shutdown, so editing them with Office open achieves nothing.

    PowerShell
    Get-Process WINWORD,EXCEL,OUTLOOK,POWERPNT -ErrorAction SilentlyContinue | Stop-Process -Force

  2. Look at what is on the lists, for every application at once.

    PowerShell
    Get-ChildItem 'HKCU:\Software\Microsoft\Office\16.0' -ErrorAction SilentlyContinue | ForEach-Object { $p = Join-Path $_.PSPath 'Resiliency'; if (Test-Path $p) { Get-ChildItem $p | Select-Object @{n='App';e={$_.PSParentPath.Split('\')[-2]}}, PSChildName } }

    DisabledItems holds hard-disabled entries and CrashingAddinList holds ones Office suspects. The values are binary blobs rather than names, so you cannot usefully read which add-in is which — clearing the key is the practical move.

  3. Clear the lists for the affected application. Change Outlook to Excel or Word as needed.

    PowerShell
    Remove-Item 'HKCU:\Software\Microsoft\Office\16.0\Outlook\Resiliency\DisabledItems' -Recurse -Force -ErrorAction SilentlyContinueRemove-Item 'HKCU:\Software\Microsoft\Office\16.0\Outlook\Resiliency\CrashingAddinList' -Recurse -Force -ErrorAction SilentlyContinue

  4. Start the application and confirm the add-in loads.

  5. If it disables itself again within a few starts, it is genuinely crashing. Update it, and treat the resiliency list as Office correctly protecting the user rather than as the fault.

Confirm it workedThe add-in is present after two or three full restarts of the application.
PowerShell
Test-Path 'HKCU:\Software\Microsoft\Office\16.0\Outlook\Resiliency\DisabledItems'
If you need to undo itThe lists rebuild themselves if Office decides to disable something again. Nothing is lost by clearing them.
Download this fix as a PowerShell script2 steps you do yourself · asks before each step
Check what the add-in is registered to do
PowerShell as administrator20 minuteslow riskreversible

The add-in is missing entirely with no message.

  1. List every registered add-in and its LoadBehavior, from both hives.

    PowerShell
    foreach ($h in 'HKCU:\Software\Microsoft\Office\Excel\Addins','HKLM:\SOFTWARE\Microsoft\Office\Excel\Addins','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Office\Excel\Addins') { Get-ChildItem $h -ErrorAction SilentlyContinue | ForEach-Object { [pscustomobject]@{ Hive=$h; Addin=$_.PSChildName; LoadBehavior=(Get-ItemProperty $_.PSPath).LoadBehavior } } }

    3 means load at startup, which is what you want. 2 means it failed and was turned off. 0 means disabled. 8 or 9 relate to load-on-demand. The WOW6432Node hive matters because a 32-bit add-in on 64-bit Office registers there and is invisible if you only look at the main key.

  2. Set it back to load at startup.

    PowerShell
    Set-ItemProperty 'HKCU:\Software\Microsoft\Office\Excel\Addins\Vendor.AddinName' -Name LoadBehavior -Type DWord -Value 3

  3. Confirm the add-in's architecture matches Office. A 32-bit COM add-in will not load into 64-bit Office at all, and this produces exactly the silent absence being reported.

    PowerShell
    Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' | Select-Object Platform

  4. If the architectures do not match, the add-in has to be replaced with the matching build — there is no client-side setting that bridges this.

Confirm it workedLoadBehavior reads 3 after a restart of the application, and the add-in appears on the ribbon.
If you need to undo itSet LoadBehavior back to its previous value.
Download this fix as a PowerShell scriptneeds an elevated shell · 1 step you do yourself · asks before each step
Stop Office disabling a known-good add-in across the estate
Group Policy or the registry, as administrator40 minutesmedium riskreversible

A business-critical add-in is being disabled on many machines and you have satisfied yourself it is healthy.

  1. Confirm it really is healthy first. This fix tells Office to stop protecting the user from it, so a genuinely crashing add-in will now take the application down every time instead of being disabled.

    The resiliency mechanism exists for a reason. Overriding it for something that actually crashes converts a manageable annoyance into repeated data loss for the user.

  2. Get the add-in's ProgID exactly as registered.

    PowerShell
    Get-ChildItem 'HKCU:\Software\Microsoft\Office\Excel\Addins' | Select-Object PSChildName

  3. Add it to the do-not-disable list for the application.

    PowerShell
    $k='HKCU:\Software\Policies\Microsoft\Office\16.0\Excel\Resiliency\DoNotDisableAddinList'New-Item $k -Force | Out-NullSet-ItemProperty $k -Name 'Vendor.AddinName' -Type DWord -Value 1

    A value of 1 keeps the add-in enabled even if it crashes or loads slowly. 0 and 2 are narrower — 1 is the setting people actually want here.

  4. Deploy it through the Office administrative templates for a fleet rather than per machine, so it survives rebuilds.

  5. Also raise the load-time threshold if the add-in is being disabled for being slow rather than for crashing — that is a separate policy under the same Resiliency branch.

Confirm it workedThe add-in stays enabled across restarts on a machine that was previously disabling it.
If you need to undo itDelete the DoNotDisableAddinList value to hand control back to Office.
Download this fix as a PowerShell scriptneeds an elevated shell · 3 steps you do yourself · asks before each step

Related faults

Office applications open slowly, hang, or start with a blank windowWindows"Microsoft has blocked macros from running because the source of this file is untrusted"WindowsA document will not open — Protected View, "file format is not valid", or a corrupt fileWindows"File is locked for editing by another user" — including when that user is youWindowsDouble-clicking a file opens Office but not the documentWindows"Cannot start Microsoft Outlook. Cannot open the Outlook window"Windows

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.