RPC_E_UNEXPECTED (0X8001FFFF) on Windows: 3 Fast Fixes

Cause #1: DCOM Permissions Got Corrupted—This Is the One You'll Hit Most Often

I've seen 0X8001FFFF more times than I can count, and nine times out of ten it's because DCOM launch and access permissions have been mangled—usually by a botched Windows update or a third-party installer that thought it knew better. You'll often see this when trying to automate Office from a script, or when Visual Studio tries to talk to a COM component during a build.

Here's the fix that works on Windows 10 22H2 and Windows 11 23H2:

1. Hit Win + R, type dcomcnfg, and press Enter. That opens Component Services.
2. Go to Component Services > Computers > My Computer > DCOM Config.
3. Look for the component that's failing—common culprits are Microsoft Office Word Application or Windows Script Host. Right-click it and pick Properties.
4. Click the Security tab. Under Launch and Activation Permissions, select Customize, then click Edit.
5. Make sure your user account (or the account running your automation—like SYSTEM or NETWORK SERVICE) has Local Launch and Local Activation checked. If not, add your account and grant both permissions.
6. Click OK all the way out, reboot, and test.

If you're not sure which COM object is the problem, open Event Viewer (eventvwr.msc), go to Windows Logs > System, and look for warnings from DCOM with ID 10010 or 10016. Those logs will name the exact CLSID. Note it down, then find that CLSID in DCOM Config to adjust permissions.

One tip: if you're a developer, skip the GUI and script permission changes with dcomperm from the Windows SDK—it's faster for bulk fixes.

Cause #2: COM+ Application Is Stuck or Corrupted

When the first fix doesn't cut it, the next suspect is a hung COM+ application. This happens a lot on servers running SQL Server Reporting Services or IIS, where a COM+ package gets left in a bad state after a crash. The error tends to surface in the Application event log as 0X8001FFFF with a source of COM+.

Here's how to flush it out:

1. Open Component Services again, go to Component Services > Computers > My Computer > COM+ Applications.
2. Look for applications that show Running but have a yellow caution icon, or ones that are Not Responding. Right-click and select Shut down.
3. If the GUI won't respond, open Command Prompt as admin and run taskkill /f /im dllhost.exe—that kills all COM+ host processes. Don't worry, Windows will restart them cleanly.
4. Then run net stop comsysapp followed by net start comsysapp. This restarts the COM+ system application cleanly.

I've also seen cases where a specific COM+ application's configuration got corrupted. Delete it entirely (make a note of its name first), then re-add it using the COM+ Application Wizard. Right-click COM+ Applications, pick New > Application, choose Create an empty application, and enter the same name. You'll need to reconfigure any roles or components, but it beats chasing ghost errors.

Cause #3: A Critical COM Registry Key Is Missing or Corrupted

Third cause, rarer but maddening: a key under HKEY_CLASSES_ROOT\CLSID or HKEY_CLASSES_ROOT\AppID got deleted or its InprocHandler32 value points to a missing DLL. This often happens after uninstalling a program that didn't clean up after itself, or after running a registry cleaner (please stop using those).

You'll know this is the case if the error appears with a specific CLSID in the event log and the first two fixes didn't help.

To check and fix:

1. Open Regedit as admin.
2. Navigate to HKEY_CLASSES_ROOT\CLSID\{your-clsid-here}. If the key is missing, you're in trouble—you'll need to reinstall the software that owns it. But if it's there, check InprocHandler32 under \InprocHandler32. Its default value should be ole32.dll. If it's blank or points to something else, change it to ole32.dll.
3. Also check HKEY_CLASSES_ROOT\AppID\{your-appid}—look for the DllSurrogate value. If it's missing when it should be empty (for in-process servers) or set to an empty string (for out-of-process), that can trip the error.

I fixed a production Exchange server once that had this exact issue—someone had run a registry optimizer that nuked the InprocHandler32 key for the MAPI COM objects. Took me two hours to find. Don't be that someone.

Quick-Reference Summary Table