CO_E_SCM_ERROR (0X80080002) fix when OLE can't bind object
OLE service fails to bind an object. Triggered by DCOM permissions or a hung OLE component. Fixes from restarting a service to resetting DCOM security.
What you're seeing
You get error 0X80080002 — CO_E_SCM_ERROR. The OLE service can't bind an object. I've seen this on Windows Server 2016, 2019, and even Windows 10. The common trigger? An application tries to use COM or DCOM to talk to another process, like an Excel automation or a legacy app that uses OLE. The culprit here is almost always one of two things: a hung OLE component, or DCOM permissions that got messed up.
Fix 1: Restart the OLE service (30 seconds)
Don't overthink this. First, restart the COM+ Event System service. It's the one that handles OLE binding. Run this in an Admin PowerShell:
Restart-Service -Name EventSystem -ForceIf that doesn't clear it, also restart COMSysApp (COM+ System Application):
Restart-Service -Name COMSysApp -ForceThen try your app again. This works about 30% of the time. If not, move on.
Fix 2: Check DCOM permissions (5 minutes)
This is the real fix about 60% of the time. The error pops up when the OLE service doesn't have the right permissions to launch or access the DCOM object. Here's how to check.
- Open Component Services — hit
Win + R, typedcomcnfg, press Enter. - Go to Component Services > Computers > My Computer.
- Right-click My Computer, choose Properties.
- Click the COM Security tab.
- Under Access Permissions, click Edit Limits.
- Make sure Everyone has Remote Access allowed. Same for Launch and Activation Permissions — Everyone should have Remote Launch and Remote Activation.
If those are missing, add them. Click OK, restart both services from Fix 1, then test. Don't bother tweaking every single COM object — that's overkill. The global permissions are usually the problem.
Fix 3: Reset DCOM default security (15 minutes)
If Fix 2 didn't work, someone's probably messed with the DCOM security defaults. Or a group policy pushed bad permissions. You'll need to reset them using the dcomcnfg command-line tool or a registry tweak.
Option A — Reset via Component Services: In the same COM Security tab, under Access Permissions, click Edit Default. Make sure SYSTEM, INTERACTIVE, and Everyone have Local Access. Under Launch and Activation Permissions, ensure SYSTEM and INTERACTIVE have Local Launch and Local Activation.
Option B — Registry reset (do this if Option A doesn't stick):
- Open Registry Editor as Admin.
- Go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. - Check the
DefaultAccessPermissionandDefaultLaunchPermissionvalues. If they're missing or empty, you might need to recreate them. - But honestly, it's easier to delete the
Olekey'sDefaultAccessPermissionandDefaultLaunchPermissionvalues — Windows will recreate them with defaults next time you open dcomcnfg. But back up the key first.
After the registry change, restart the server or at least reboot the COMSysApp service. Test your app. If it still fails, you're looking at a deeper issue — maybe a corrupt COM+ catalog.
Fix 4: Re-register OLE components (10 minutes)
This is for the rare case where the OLE DLLs got unregistered. Do this:
regsvr32 ole32.dll /s
regsvr32 oleaut32.dll /s
regsvr32 olepro32.dll /s
regsvr32 actxprxy.dll /sThen restart the EventSystem service. I've seen this fix a weird binding issue after a Windows Update.
Fix 5: Event log check for DCOM errors
Before you waste more time, check the System and Application event logs for event ID 10016. That's the DCOM permission error. Look for details like CLSID and APPID. If you find one, you can give that specific COM object the permissions it needs. But that's a deep rabbit hole — stick with the global fixes first.
Pro tip: If this is happening on a server that runs a legacy app, the app's developer probably hardcoded DCOM settings. In that case, you'll need to match the permissions to what the app expects. Check the app's documentation for the CLSID and set it under Component Services > Computers > My Computer > DCOM Config.
When to call it
If none of these fixes get rid of the error, you might have a corrupted COM+ catalog. That's rare but happens. You'd need to rebuild the catalog using comprepair.cmd — but that's a last resort and I'd only do it after backing up the COM+ applications. Most of the time, Fix 2 or Fix 3 will get you sorted.
Was this solution helpful?