OLE invalid header 0x80010111 - 3 quick fixes

Cause #1: Corrupted or missing COM registration

This is the one I see most often. The OLE layer can't find the right class ID in the registry. Happens after a failed Office update or a half-baked uninstall of some old COM object. You'll get 0x80010111 when launching Outlook, Excel, or any app that talks to a COM server.

Fix it — re-register the COM components

1. Open an elevated Command Prompt (Run as Administrator).
2. Run these commands in order. Don't skip any.

regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s actxprxy.dll
regsvr32 /s urlmon.dll
regsvr32 /s mshtml.dll

The /s flag runs them silent — you won't see confirmation popups. That's fine. Each one re-registers the core OLE and COM libraries. If one fails, note the error code. Usually it's a permissions issue — make sure you're actually running as admin.

After that, reboot. Test the app. If the error's gone, you're done. This fixes about 60% of cases.

Cause #2: DCOM permission issues

When the fix above doesn't work, the culprit is almost always DCOM permissions. The error fires because the user account calling the COM object doesn't have launch or activation rights. I've seen this on Terminal Servers and RDS environments constantly. Also happens after a domain migration or when you switch from local to domain accounts.

Fix it — grant DCOM launch permissions

1. Press Win + R, type dcomcnfg, hit Enter.
2. Expand Component Services > Computers > right-click My Computer > Properties.
3. Go to the COM Security tab.
4. Under Launch and Activation Permissions, click Edit Limits.
5. Add the user or group that's hitting the error. Give them Local Launch and Local Activation.
6. Do the same under Access Permissions — give Local Access.
7. Click OK all the way out, reboot.

If you're in a domain, push this via Group Policy. Computer Configuration > Administrative Templates > Windows Components > Application Compatibility has a policy called "Turn off Application Compatibility Engine" — don't touch that. The setting you want is under System > COM for DCOM permissions, but honestly it's easier to deploy via script.

Here's a PowerShell snippet that sets the launch permission for "Everyone" on My Computer. Use with caution — test first.

$SD = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Ole' -Name 'DefaultLaunchPermission'
$SD.DefaultLaunchPermission

You'll need to decode that SDDL, but for most folks the GUI is safer.

Cause #3: Anti-virus or security software blocking COM

Third most common — and the one everyone forgets to check. Some AV suites hook into the COM subsystem to intercept OLE calls. When they do it wrong, you get 0x80010111. I've seen this with McAfee, Symantec Endpoint Protection, and Trend Micro. The error often shows up in event logs as Event ID 1001 from the COM subsystem.

Fix it — exclude the offending process or disable COM interception

1. Temporarily disable the real-time protection. Not just the notifications — actually stop the service.
2. Test the app. If the error disappears, you found the cause.
3. Re-enable protection, then add the application that was failing to the AV exclusion list.
4. If that doesn't work, look for a setting called "COM Interception" or "OLE Protection" in the AV console. Turn it off.

Don't just leave AV disabled. That's asking for trouble. But excluding the app is usually fine — Outlook calling a COM add-in isn't a threat vector.

Quick way to confirm: check the Application event log for 0x80010111 and note the CLSID. Look up that CLSID in the registry under HKCR\CLSID\{...}. That tells you which COM object is failing. Then you know which app to exclude.

Quick-reference summary table

If none of these work, you're probably dealing with a corrupted user profile. Create a test user, log in, try the app. If it works, migrate the old profile's data and nuke the corrupt one. That's a last resort — but it's saved my skin more than once.