Why ActiveX Stops Working in Office 2024/Microsoft 365 and How to Diagnose It

What You Need to Know First

In Office 2024 and Microsoft 365, ActiveX controls are disabled by default. When Excel buttons and forms, or embedded objects in Word / PowerPoint, suddenly appear to “stop working” after an update, the cause is usually not a broken program but a change in security defaults.

The causes fall into three broad categories.

1. Security setting changes (Trust Center, ActiveX disabled by default)
2. 32-bit / 64-bit mismatch (loading a 32-bit-only control into 64-bit Office)
3. Missing COM registration or dependent DLLs / runtimes (regsvr32 never run, missing VC++ runtime)

Field rule of thumb: Working through these from the top, in this order, is the fastest path.

Office 2024 vs Microsoft 365 — What Is Different

Important: The registry path remains 16.0 even in Office 2024. Searching for 24.0 “because it’s 2024” is a classic detour.

A Note on Windows 10

General support for Windows 10 ended on October 14, 2025. However, Microsoft 365 Apps remains in a migration grace period on Windows 10, with security updates provided until October 10, 2028. In other words, the situation is this:

• It is not the case that “nothing works at all on Windows 10”
• You are operating under the dual premise of “OS out of support, Apps in a grace period”

Troubleshooting Overview

flowchart TD
    A[Reproduce the symptom] --> B[Collect Office product name, build, bitness, and OS information]
    B --> C{Are the OS / Office support prerequisites OK?}
    C -- No --> C1[Fix prerequisites: review OS / Office edition / channel]
    C -- Yes --> D[Check the Trust Center]
    D --> E{Problem with ActiveX settings / Protected View / Trusted Documents?}
    E -- Yes --> E1[Fix settings, signing, and distribution design]
    E -- No --> F{Depends on legacy Web / IE?}
    F -- Yes --> F1[Check IE mode and the site list]
    F -- No --> G[Check CLSID / InprocServer32 / TypeLib]
    G --> H{Is COM registration healthy?}
    H -- No --> H1[regsvr32 / RegAsm / reinstall]
    H -- Yes --> I[Check dependent DLLs / .NET / VC++ runtimes]
    I --> J{Are the dependencies satisfied?}
    J -- No --> J1[Repair and redistribute the relevant runtime]
    J -- Yes --> K[Collect logs / Procmon / Process Explorer]
    K --> L[Check build deltas and security update deltas]

Step 1 — Collect Environment Information

First, always record the following information. The point is to make decisions based on numbers, not gut feeling.

On the Office side

• Check under [File] → [Account] → [Product Information]
  • Product name (Office 2024 vs Microsoft 365)
  • Version and build number (most important)
  • Installation type (Click-to-Run)
• Check 32-bit / 64-bit in the product information dialog under [About Excel] / [About Word], etc.

On the Windows side

# Basic OS information
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber, OSArchitecture

# Executable paths of Office processes
Get-Process WINWORD, EXCEL, POWERPNT, VISIO -ErrorAction SilentlyContinue |
  Select-Object ProcessName, Path

Common pitfalls

Step 2 — Check the Trust Center and Security Settings

What you are doing here is determining whether “the file itself is being blocked” or “loading the COM component is failing”.

Checklist (in order, from the top)

What to try first

1. Copy the problem file to a locally managed folder (e.g., C:\Temp) and save it under a different name
2. Avoid opening it directly from a network share or email attachment (to rule out Protected View)
3. Start Office in safe mode to isolate the influence of add-ins

excel /safe
winword /safe
powerpnt /safe

Step 3 — Check Whether It Depends on IE Mode

There are cases where what looked like an “ordinary ActiveX failure” turns out to be caused by Edge’s IE mode not being configured.

• IE mode is not a browser-wide switch — it applies only to sites registered in the Enterprise Site List
• If only part of your internal web integration is failing, check whether that site is actually covered by IE mode

Check the following:

• Edge policies: Administrative Templates > Microsoft Edge
• Registry: HKLM\SOFTWARE\Policies\Microsoft\Edge
• Diagnostics page: edge://compat/iediagnostic

Step 4 — Check COM Registration

If the Trust Center is clean, the next thing to verify is whether the COM component itself is correctly registered.

Basic verification commands

:: Check CLSID registration status
reg query "HKLM\SOFTWARE\Classes\CLSID\{YOUR-CLSID-HERE}\InprocServer32" /s

:: Register / unregister a native COM / ActiveX DLL
regsvr32 C:\Path\YourControl.dll
regsvr32 /u C:\Path\YourControl.dll

For COM components built with .NET (important)

regsvr32 cannot be used for .NET assemblies. Use RegAsm.

:: 32bit Office on 64bit Windows -> use the Framework RegAsm
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

:: 64bit Office -> use the Framework64 RegAsm
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

Typical accident: “The RegAsm bitness does not match the Office bitness” — registration succeeds in the registry, but Office cannot find it.

Step 5 — Check Dependent DLLs / Runtimes

When “the main DLL exists but won’t load,” the most common case is a missing dependency.

Runtimes that are frequently missing in practice

Low-level investigation tools

Capture a Procmon log while reproducing the issue and filter on NAME NOT FOUND, and it becomes immediately clear which DLL or registry key could not be found.

Step 6 — Capture Logs for Final Confirmation

If the cause has not been identified by this point, enable logging and catch the moment of reproduction.

Enable general Office logging

reg add HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /t REG_DWORD /d 1

Enable detailed Click-to-Run logging

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1

Logs are written to %windir%\temp or %temp%.

Use Event Viewer alongside

eventvwr.msc

• Check Windows Logs > Application
• .NET Runtime and SideBySide errors are often the decisive clue

Disable logging after verification (don’t forget)

reg delete HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

Key Registry / Policy Quick Reference

Four paths worth memorizing

With 32-bit Office on 64-bit Windows, also check under Wow6432Node for anything COM-related.

Frequently used test registry entries (verification only)

Windows Registry Editor Version 5.00

; Test only: lift the blanket ActiveX disable
[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]
"DisableAllActiveX"=dword:00000000

Warning: These settings are for verification only. The permanent fix should be “a trusted distribution path plus signing.”

Common Symptoms and Remedies

Recommended Settings for Enterprises

The fundamental principle of a permanent fix is “don’t lower security across the board — allow only what is needed, narrowly”.

Example Microsoft 365 deployment configuration (32-bit + Monthly Enterprise)

<Configuration>
  <Add OfficeClientEdition="32" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Last Resort — Repair

• Quick Repair / Online Repair does work for settings and registration corruption
• However, it does not solve x86 / x64 mismatches or signing / policy problems themselves
• Repair comes last (doing it first contaminates your investigation logs)

Command Quick Reference

Conclusion — Don’t Get the Order Wrong

Misconfiguration -> OS / bitness mismatch -> COM component problem -> dependencies -> update deltas

Even when an ActiveX problem looks like “just an Excel issue,” it is in fact a problem where five layers intersect: Office’s default security + Windows support prerequisites + COM component registration + dependent runtimes + the update model. Rather than blindly relaxing settings, isolate the cause from the top down and you will reach a repair that is far less likely to recur.

Reference Links

• ActiveX controls are disabled by default in Microsoft 365 and Office 2024 — scope of impact of the default disablement
• Enable or disable ActiveX settings in Office files — the resource closest to user operations
• Update history for Office LTSC 2024 and Office 2024 — build comparisons, pre/post-update deltas
• Overview of update channels for Microsoft 365 Apps — differences between Current / Monthly Enterprise / Semi-Annual
• Release Information for Updates to Microsoft 365 Apps — channel-driven behavioral differences
• Compatibility between the 32-bit and 64-bit versions of Office — decision criteria when ActiveX / COM assets are involved
• Internet Explorer mode in Microsoft Edge — Enterprise Site List and policies
• regsvr32 command — registering / unregistering native COM
• Regasm.exe (Assembly Registration Tool) — registering COM components built with .NET
• Process Monitor (Procmon) — tracking NAME NOT FOUND / PATH NOT FOUND
• Process Explorer — DLL load status of a process
• Latest supported Visual C++ Redistributable Downloads — where to check for missing VC++ runtimes
• .NET Framework installation guide — checking .NET Framework versions

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.