0X80080003

Fixing 0x80080003: CO_E_SCM_RPC_FAILURE on Windows Server

Server & Cloud Intermediate 👁 9 views 📅 May 27, 2026

RPC call to the OLE service failed. Usually a dead DCOM or RPC service, corrupted user profile, or a permissions issue. The fix is almost always restarting services or rebuilding the profile.

Cause #1: DCOM or RPC Service is Hung or Stopped

This is the one I see 80% of the time. The DCOM Server Process Launcher or Remote Procedure Call (RPC) service gets stuck — not fully stopped, but in a zombie state. The OLE service can't talk to RPC, throws 0x80080003, and your COM+ application or third-party tool fails. This happens often after a Windows Update reboot that didn't finish cleanly, or if someone killed a hung DCOM host process via Task Manager.

Check service state

Run services.msc and look for these three services:

  • DCOM Server Process Launcher (DcomLaunch)
  • Remote Procedure Call (RPC) (RpcSs)
  • RPC Endpoint Mapper (RpcEptMapper)

They should all show Running. If any are stopped or stuck on Starting, you've found the culprit.

Fix: Restart services in order

Don't just restart RPC — DCOM depends on it. Do this from an admin PowerShell or CMD:

net stop DcomLaunch /y
net stop RpcSs /y
net start RpcSs
net start DcomLaunch

The /y flag tells dependent services to shut down cleanly. If the services won't stop (common on Server 2016), force kill the PID:

taskkill /f /im svchost.exe /fi "SERVICES eq DcomLaunch"
# then restart as above

Test your app immediately. If the error's gone, you're done. If not, move to the next cause.

Cause #2: Corrupted User Profile (the sneaky one)

I've burned hours on this. A corrupted NTUSER.DAT or a user profile that's partially loaded can break DCOM's ability to launch the OLE service. The RPC call succeeds, but the COM runtime can't load the profile's registry hive for the impersonated user. This shows up when the error happens only for a specific user or after a profile migration.

How to confirm

Look at the Application event log for Event ID 1000 or 1001 with source Microsoft-Windows-DistributedCOM. If you see text like "The user SID ... did not have a proper profile loaded", it's the profile.

Fix: Rebuild the user profile

  1. Log in as a different admin account.
  2. Go to System Properties > Advanced > User Profiles.
  3. Select the broken user's profile and click Delete.
  4. Delete the user's folder in C:\Users\ (backup data first!).
  5. Have the user log in again to create a fresh profile.

If the profile won't delete ("in use"), boot into Safe Mode and delete it from there. On Server Core, use wmic useraccount or net user to recreate the account. This fix works every time for profile-related 0x80080003.

Cause #3: DCOM Permissions Misconfiguration

Less common but vicious — someone tightened security or a GPO changed the default DCOM launch and activation permissions. The OLE service can't get the right tokens to launch the COM object. You'll see this when the error pops up after a security audit or GPO update.

Check permissions

Open dcomcnfg (Component Services). Navigate to Component Services > Computers > My Computer. Right-click My Computer and select Properties. Go to the COM Security tab.

Under Launch and Activation Permissions, click Edit Limits. Ensure these accounts have Local Launch and Local Activation at minimum:

  • Administrators
  • Everyone (yes, Everyone — required for COM+ to work with SYSTEM context)
  • NETWORK SERVICE
  • LOCAL SERVICE

Fix: Reset to defaults

If you're not sure what changed, reset the COM security to defaults:

# From an admin PowerShell
$com = Get-WmiObject -Class Win32_Process -Filter "Name='mmc.exe'"
# Actually, use this registry reset instead:
reg delete "HKLM\SOFTWARE\Microsoft\Ole" /v DefaultLaunchPermission /f
reg delete "HKLM\SOFTWARE\Microsoft\Ole" /v MachineAccessRestriction /f
reg delete "HKLM\SOFTWARE\Microsoft\Ole" /v MachineLaunchRestriction /f

Reboot the server. Windows will recreate the default permissions on next startup. If you're on a domain-joined server and a GPO pushes custom permissions, talk to your AD team before doing this — the GPO will just overwrite it again.

Quick-Reference Summary

CauseQuick FixBest Indicator
Hung DCOM/RPC servicesRestart DcomLaunch and RpcSs in orderServices stuck on "Starting"
Corrupted user profileDelete and recreate the user profileEvent ID 1000, profile errors
DCOM permissions changedReset Ole registry keys, rebootError after GPO or security change

Start with the service restart — it's quick, zero risk, and fixes most cases. Profile rebuild second if the error follows a user. Permissions reset last, but only if you've ruled out the first two.

Was this solution helpful?