NOTICE: Click-to-run is breaking OneMore

[stevencohn]

OneMore may fail to load in corporate environments that explicitly intercept Office add-ins hosted by dllhost.exe and redirect that to a virtualized isolation host using AppVDllSurrogate32.exe.

You can detect this by looking for a process named AppVDllSurrogate32 with the OneMore App GUID {88AB88AB-CDFB-4C68-9C3A-F10B75A5BC61} as a command line parameter.

Your company may be forcing this through Registry settings, group policy, or a security tool such as Cyberark.

Registry inceptors can be disabled manually. But both group policy and Cyberark settings need to be discussed with your local IT department; there's nothing OneMore can do to circumvent these.

UPDATE Apr 9, 2026

Microsoft 365 Apps for Enterprise
With version Microsoft® OneNote® for Microsoft 365 MSO (Version 2603 Build 16.0.19822.20086) 32-bit

Office now uses Click-to-run activation for add-ins. This forces AppVDllSurrogate isolation. It is possible to force Office to load add-ins using dllhost, but that appears to be broken.

I've yet to find a solution. I'll be opening a ticket/question with Microsoft, but this might mean the end of OneMore for anyone using newer versions of Office 365... I'll do my best...

[stevencohn]

Copilot Conversation

You’re right to conclude that running a OneNote COM add‑in inside AppVDllSurrogate32 is not a supported or documented scenario. And the fact that it used to work a few weeks ago is the most important clue — something in your environment changed, not your add‑in.
Let’s cut straight to the practical reality: You have two goals:
1. Stop Office from hosting your add‑in inside AppVDllSurrogate32
2. Get it back into dllhost.exe where it works
And you want to know what your actual options are.
Below is the clearest, most actionable breakdown of what you can do.
⭐ First: What changed?
Given your symptoms, the most likely triggers are:

1. Office Click‑to‑Run updated
   Office C2R updates silently and frequently. Microsoft has been tightening virtualization boundaries in recent builds, especially around COM activation.
   This alone can cause a COM add‑in to suddenly be hosted in the Office AppV surrogate.
2. A new enterprise policy or security rule was deployed
   Even a small change in:
   • AppLocker
   • WDAC
   • CyberArk / BeyondTrust / Ivanti
   • FSLogix
   • App‑V client policies
   …can cause dllhost.exe to be restricted, which forces Office to fall back to its own surrogate.
3. A registry change to the AppID or CLSID
   Even if you didn’t change it, a system update or policy could have.
   ⭐ Second: What are your real options?
   Below are the only viable paths to get your add‑in out of AppVDllSurrogate32 and back into dllhost.exe.
   I’ll list them from most realistic to least disruptive.
   ✅ Option 1 — Remove the AppID → DllSurrogate mapping
   Right now your AppID has:
   Code

DllSurrogate = ""
This tells COM: “Run me out‑of‑proc in a surrogate.”
Under C2R, the surrogate is AppVDllSurrogate32.exe, not dllhost.exe.
If you remove the AppID key entirely, or remove the DllSurrogate value, COM will try to load your add‑in in‑proc (inside OneNote.exe) instead of using any surrogate.
Pros
• Fastest fix
• Avoids AppVDllSurrogate32 entirely
• Often restores functionality immediately
Cons
• Your add‑in must be safe to run in‑proc
• If it was originally designed for out‑of‑proc, this may not be ideal
If you want, I can tell you exactly which registry keys to adjust (safely).
✅ Option 2 — Convert the add‑in to a LocalServer COM server
Instead of:
Code

InprocServer32 = mscoree.dll
You register:
Code

LocalServer32 = "path\to\your\exe"
This forces COM to launch your own EXE as the host process — not dllhost, not AppVDllSurrogate32.
Pros
• 100% bypasses Office virtualization
• Gives you full control over the hosting process
• Very stable for .NET add‑ins
Cons
• Requires packaging your add‑in as an EXE
• Slightly more work
This is the most robust long‑term fix.
✅ Option 3 — Force COM to use dllhost.exe explicitly
You can override the surrogate selection by setting:
Code

DllSurrogateExecutable = C:\Windows\System32\dllhost.exe
This is not commonly used, but it does work.
Pros
• Keeps the add‑in out‑of‑proc
• Forces dllhost.exe even under C2R
• Minimal code changes
Cons
• Not officially documented
• May be overridden by enterprise policies
⚠️ Option 4 — Install OneNote MSI (only if your org has access)
This avoids C2R entirely.
Pros
• No AppVDllSurrogate32
• COM add‑ins behave normally
Cons
• Only available through Volume Licensing
• Cannot coexist with C2R Office
• Not future‑proof
⚠️ Option 5 — Roll back the Office C2R build
If this broke “a couple of weeks ago,” rolling back to a known‑good build may restore dllhost hosting.
Pros
• Quick test
• Confirms whether Office updates caused the issue
Cons
• Not a long‑term solution
• Your IT department may block rollback
❌ What you cannot do
Just so expectations are clear:
• You cannot configure Office C2R to “stop using AppVDllSurrogate32.”
• You cannot disable the Office virtualization layer.
• You cannot force OneNote to use MSI unless you reinstall Office entirely.
• You cannot make AppVDllSurrogate32 behave like dllhost — they are not equivalent.
⭐ My recommendation (based on everything you’ve shared)
Best immediate fix:
➡️ Remove the AppID → DllSurrogate mapping This forces the add‑in to load in‑proc and bypasses the surrogate entirely.
Best long‑term fix:
➡️ Convert the add‑in to a LocalServer COM server This gives you full control and avoids Office virtualization forever.
If you want, I can walk you through:
• The exact registry keys to modify
• How to safely test in‑proc loading
• How to convert your add‑in to LocalServer32
• How to confirm whether Office updates caused the change
• How to check whether a security tool is interfering
Just tell me which direction you want to go.
Tell me more about option 3
Option 3 is the “surgical” fix — the one that keeps your add‑in out‑of‑proc, avoids AppVDllSurrogate32, and forces COM to use dllhost.exe even under Office Click‑to‑Run. It’s not widely known, but it is a real COM feature, and it works because COM lets you explicitly override the surrogate executable.
Let me walk you through it clearly and safely.
⭐ What Option 3 Actually Does
Normally, when a COM object has:
Code

DllSurrogate = ""
Windows chooses the default surrogate:
• On a normal system → dllhost.exe
• Under Office C2R → AppVDllSurrogate32.exe (Office’s private surrogate)
Option 3 overrides that choice by adding:
Code

DllSurrogateExecutable = C:\Windows\System32\dllhost.exe
This tells COM:
“Ignore whatever surrogate the environment wants. Use this executable as the surrogate host.”
This is a documented COM behavior, but rarely used.
⭐ Why this works under Office C2R
Office C2R replaces the default surrogate with its own AppV‑style surrogate. But if you explicitly specify a surrogate executable, COM respects that and bypasses the Office virtualization layer.
So instead of:
Code

AppVDllSurrogate32.exe {GUID} -Embedding
You get:
Code

dllhost.exe /Processid:{GUID}
And your add‑in runs in the environment it was designed for.
⭐ Where this setting goes
It belongs under the AppID key for your add‑in.
You already found:
Code

HKCR\AppID{Your-AppID-GUID}
Inside that key, you add:
Code

DllSurrogateExecutable = C:\Windows\System32\dllhost.exe
You can leave DllSurrogate="" in place — COM will prefer the explicit executable.
⭐ What this achieves
• Forces dllhost.exe even under Office C2R
• Avoids AppVDllSurrogate32 entirely
• Keeps the add‑in out‑of‑proc (no in‑proc risk)
• Requires no code changes
• Reverts behavior to what you had “a couple of weeks ago”
This is the closest thing to a “restore the old behavior” switch.
⭐ When this is the right choice
Option 3 is ideal when:
• The add‑in is stable out‑of‑proc
• The add‑in breaks under AppVDllSurrogate32
• You don’t want to run in‑proc
• You don’t want to rewrite the add‑in as a LocalServer EXE
• You want the smallest possible change
This is exactly your situation.
⭐ When this might not work
There are only two blockers:

1. Enterprise security tools override surrogate selection
   If dllhost.exe is blocked by AppLocker/WDAC, COM will still fail.
2. Office C2R update explicitly forces virtualization
   This is rare, but possible in some builds.
   If either of these is true, we can still work around it — but Option 3 won’t be enough by itself.
   ⭐ What I recommend next
   Before you make any changes, I’d like to confirm one thing:
   👉 Is dllhost.exe allowed to run on your system?
   If dllhost.exe is blocked by a security policy, forcing COM to use it won’t help.
   You can check quickly:
   1. Open Task Manager
   2. Look for any running dllhost.exe processes
      ○ If you see any, you’re good
      ○ If you see none, and AppVDllSurrogate32 is everywhere, dllhost may be restricted
      If you want, tell me what you see — that will tell us whether Option 3 will work immediately or whether we need to adjust the plan.
      If you want, I can also walk you through:
      • The exact registry steps
      • How to test safely without breaking anything
      • How to confirm COM is using dllhost afterward
      • How to undo the change if needed
      Just let me know how you want to proceed.
      OK DllSurrogateExecutable is set and it's no longer starting AppVDllSurrogate32. It does start dllhost and I see the add-in logging its startup in its log file. However, dllhost.exe is terminated after a few seconds.
      Good — this tells us two important things:
   3. Your override worked. COM is now launching dllhost.exe instead of AppVDllSurrogate32.exe.
   4. dllhost.exe is crashing or being terminated, which means the add‑in is failing early during COM activation.
      That narrows the problem dramatically. Now we can focus on why dllhost is dying.
      Below is the clean, structured way to diagnose this — and the likely causes based on what you’ve already told me.
      ⭐ Why dllhost.exe terminates after a few seconds
      When COM launches a surrogate, it expects the COM server (your add‑in) to:
      • Load successfully
      • Register its class objects
      • Call CoRegisterClassObject
      • Enter a message loop
      If any of these fail, COM tears down the surrogate process.
      So the fact that dllhost starts and then disappears means:
      Your add‑in is not completing COM activation successfully when hosted in dllhost.exe.
      This is not unusual for .NET COM add‑ins that were originally designed to run under Office’s AppV surrogate.
      ⭐ The 4 most likely causes (based on your symptoms)
3. The add‑in is missing dependencies when hosted in dllhost.exe
   Under AppVDllSurrogate32, Office provides a virtualized environment with:
   • Office assemblies
   • Office registry overlays
   • Virtualized file paths
   • Virtualized COM registrations
   dllhost.exe does not provide these.
   If your add‑in loads:
   • Office interop assemblies
   • Other COM components
   • Native DLLs
   • Config files
   • Registry keys under HKCU\Software\Microsoft\Office
   …dllhost may not be able to find them.
   This is the Reorder dialog #1 cause of dllhost dying silently.
4. The add‑in is trying to load Office APIs that require the Office virtualization layer
   Some Office APIs only work when hosted inside the Office C2R AppV environment.
   If your add‑in calls into:
   • OneNote API
   • Office extensibility APIs
   • Office COM objects
   • Office shared components
   …dllhost may not have access to them.
   AppVDllSurrogate32 does.
5. The add‑in is throwing an unhandled exception during startup
   If your add‑in logs “startup” but not “initialized,” it may be failing after the first few lines.
   dllhost.exe will terminate immediately if:
   • The .NET runtime throws
   • A dependency fails to load
   • A COM registration fails
   • A constructor throws
   • A static initializer throws
   AppVDllSurrogate32 may swallow or virtualize these failures.
   dllhost does not.
6. The add‑in is registered as InProcServer32 but expects to run out‑of‑proc
   Your add‑in is a .NET COM server registered like this:
   Code

InprocServer32 = mscoree.dll
This is normal for .NET COM servers, but:
• Running out‑of‑proc via dllhost is a special case
• The .NET loader must marshal correctly
• If the add‑in expects the Office AppV environment, dllhost may not provide it
This mismatch can cause dllhost to exit.
⭐ What to do next (in order of usefulness)
Step 1 — Check the Windows Event Log
This is the fastest way to see why dllhost died.
Look under:
Event Viewer → Windows Logs → Application
Filter for:
• dllhost.exe
• .NET Runtime
• Application Error
If you see:
• Faulting module: mscoree.dll
• Unhandled exception
• FileNotFoundException
• TypeLoadException
• COM activation failed
…we’ll know exactly what’s missing.
If you can share the event text (minus sensitive info), I can interpret it.
Step 2 — Enable Fusion logging (for .NET assembly load failures)
If the add‑in is missing a DLL, Fusion logging will show it immediately.
I can walk you through enabling it if you want.
Step 3 — Check whether the add‑in depends on Office C2R virtualization
If the add‑in:
• Reads Office registry keys
• Loads Office DLLs
• Uses OneNote interop
• Uses Office shared components
…it may require the Office virtual environment that AppVDllSurrogate32 provides.
dllhost.exe does not provide that environment.
Step 4 — Consider switching to LocalServer32 (Option 2)
If the add‑in cannot run in dllhost.exe because it needs:
• A custom environment
• Custom dependencies
• Office virtualization
…then the best fix is to host it in your own EXE, not dllhost.
This gives you:
• Full control
• Full logging
• Full dependency resolution
• No Office virtualization
• No surrogate surprises
This is the most robust long‑term fix.
⭐ What I need from you to pinpoint the exact cause
If you can provide any one of these, I can tell you exactly why dllhost is dying:
1. The Application Error event from Event Viewer
2. The .NET Runtime error event
3. The last few lines of your add‑in’s log before dllhost exits
4. Whether the add‑in loads any Office DLLs or COM objects during startup
Even one of these will give us the answer.

[stevencohn]

Click-to-run info

Microsoft Office Click-to-Run is a background service that installs, updates, and runs Office applications using virtualization technology, allowing you to use Office apps while updates or installations occur.

What Click-to-Run Is
Click-to-Run (C2R) is a streaming and virtualization technology developed by Microsoft to deploy Office applications efficiently. It allows users to start using Office apps almost immediately during installation, without waiting for the full suite to download. The service also automatically updates Office products in the background, ensuring the latest features and security patches are applied. It runs continuously in the background, managing updates, licensing, and streaming of Office applications.

Why It Runs in the Background
The Click-to-Run process is designed to run automatically whenever Windows starts or when Office apps are used. It consumes minimal system resources under normal conditions, but it may temporarily use higher CPU or disk resources when installing updates or performing maintenance. Even if you do not actively use Office, the service may still run to check for updates or maintain Office components. If Office was pre-installed or a trial version exists, Click-to-Run may appear even if you never opened Office.

Managing or Disabling Click-to-Run
If you want to reduce resource usage or disable Click-to-Run, there are several methods:
Using Windows Services:
Press Win + R, type services.msc, and press Enter.
Locate Microsoft Office Click-to-Run Service (ClickToRunSvc).
Right-click, select Stop, then go to Properties and set Startup type to Disabled.
Restart your computer to apply changes.

Control Panel or Office Settings:
Open Programs and Features in Control Panel.
Right-click Microsoft Office, select Change, and choose options to repair, update, or uninstall Click-to-Run.

Alternative Office Installation:
Download a version of Office that uses the traditional MSI installer instead of Click-to-Run from your Microsoft account, which avoids the background service.

Considerations
Disabling Click-to-Run may prevent automatic updates, leaving Office vulnerable to security risks.
Some Office features may malfunction or require reactivation if the service is disabled.
High CPU usage is often temporary during updates; verify the executable location to ensure it is legitimate and not malware.

By understanding Click-to-Run, you can decide whether to leave it running for automatic updates or manage it to reduce background resource usage while maintaining Office functionality.

[stevencohn]

No luck in my enterprise environment. My business laptop is tightly controlled by IT.

• I've tried disabling Microsoft Office Click-to-Run Service. But Office apps will no longer start at all without that.
• I do not have permission on my enterprise laptop to modify the Microsoft 365 Apps installation.

At this time, I don't know of any workarounds to get OneMore to work.

[StephenMSmith]

I baffled b/c I'm using the same Office LTSC on both my desktop and laptop, neither of which are part of a corporation environment. I have this problem on my desktop but no problems on my laptop. Anything you can think of that I should compare that might help resolve? Why does it even work on my laptop?

Working:

Not Working:

[stevencohn]

Welcome to my world - a harsh landscape of reverse-engineering Microsoft land mines.

[StephenMSmith]

I hear you. Keep up the amazing work!

I'll do some investigation and try to figure out why OneMore works fine on my laptop when theoretically it should have this same problem documented in this thread like my desktop does.

[stevencohn]

No luck in my enterprise environment. My business laptop is tightly controlled by IT.

• I've tried disabling Microsoft Office Click-to-Run Service. But Office apps will no longer start at all without that.
• I do not have permission on my enterprise laptop to modify the Microsoft 365 Apps installation.

At this time, I don't know of any workarounds to get OneMore to work.

I was able to solve this on my corporate laptop by re-installing an older version of OneNote. I don't know if this is a temporary fix - it might break again the next time IT decides to update Office on my laptop! - but at least for now, reinstalling OneNote might be a solution ??

[StephenMSmith]

And I just realized one big difference b/t my OFfice 2024 LTSC on laptop w/working OneMore and my Office 2024 LTSC on desktop w/broken OneMore due to above. My desktop keeps identifying an update but fails to install:

[dwillis77]

So this is only happening with certain security configurations in the newest Click-to-Run Office 365 installations? Or it's happening with default installs of the latest O365?

FWIW, I'm on v2603 and it seems to be working fine for now (on multiple different machines, all using that version of OneNote, all on Win10 LTSC), knock on wood....

[stevencohn]

I'm glad you got it working. I'm not sure what the exact culprit is yet.