Fix CO_E_OBJNOTCONNECTED (0X800401FD) in COM/DCOM apps

Quick answer

Reinitialize the COM interface pointer from scratch — the existing one is stale. Call CoCreateInstance (or CoGetClassObject) again to get a fresh connection to the server.

What's actually happening here

You're getting CO_E_OBJNOTCONNECTED (0x800401FD) when your code tries to call a method on a COM or DCOM object, but the underlying RPC connection to the server object has been dropped. This isn't a permission error — it's a connectivity error. The interface pointer you're holding was valid at one point, but something killed the channel between your client and the server.

Typical triggers: the remote server rebooted, the DCOM process crashed, a firewall closed the port mid-session, or the RPC timeout (often 2 minutes by default) expired while your code was idle. I've seen this most often in automation scripts that open a COM object, wait a few minutes for user input or a long file operation, then try to use the pointer again.

The error code 0x800401FD maps to CO_E_OBJNOTCONNECTED — the object is alive in memory but its transport layer (the RPC channel) is gone. You can't just retry the same call; you must re-obtain the interface.

Fix steps

1. Reinitialize the interface pointer. In your code, release the current pointer (pInterface->Release() in C++) and call CoCreateInstance again. For PowerShell or VBScript, set the variable to $null or Nothing and re-create the object.

   // C++ example
   pMyObj->Release(); // release stale pointer
   hr = CoCreateInstance(CLSID_MyServer, NULL, CLSCTX_LOCAL_SERVER, IID_IMyInterface, (void**)&pMyObj);
   if (FAILED(hr)) { /* handle error */ }

2. Check DCOM permissions on the server. If the issue reoccurs every few minutes, the server might be rejecting your client due to authentication timeout. On the server machine, run dcomcnfg, go to Component Services → Computers → My Computer → DCOM Config. Find your server's CLSID or application name, right-click → Properties → Security tab. Under Launch and Activation Permissions, edit the list to include your client user account with Allow for all four permissions. Under Access Permissions, do the same.
3. Increase the DCOM timeout. On the client machine, open Registry Editor. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. Create or edit a DWORD named DefaultTimeout and set it to 120000 (2 minutes) or higher like 300000 (5 minutes) in milliseconds. Reboot or restart the COM+ service.
4. Restart the COM+ application or DCOM server process. Open Component Services, expand Component Services → Computers → My Computer → COM+ Applications. Right-click your application → Shut down. Wait a few seconds, then right-click → Start. If it's a regular DCOM server (not COM+), kill the server process in Task Manager — it will auto-restart on the next client request.
5. Test with a simple client. Write a minimal script in PowerShell to create the object and call a trivial method:

   $obj = New-Object -ComObject Your.Application
   $obj.YourMethod() # replace with actual method

   If this works but your real client fails, the issue is timing — your real code is holding the pointer too long between calls.

Alternative fixes if the main one fails

• Disable the COM firewall exception. If the server is remote, the Windows Firewall may be closing RPC dynamic ports. Add a static endpoint for your DCOM application (use dcomcnfg → Properties → Endpoints tab), then open that port in the firewall.
• Switch to a different threading model. If your client is using COINIT_APARTMENTTHREADED, try COINIT_MULTITHREADED (or vice versa). Some DCOM servers expect a specific model and disconnect mismatched clients.
• Replace DCOM with a named pipe. If the server is local, consider rewriting the IPC to use named pipes or a local TCP socket — DCOM's overhead and timeout behavior won't apply.

Prevention tip

The cleanest way to avoid CO_E_OBJNOTCONNECTED in production code is to treat every COM interface pointer as a short-lived resource. Don't cache it for longer than a few seconds. If your workflow requires long pauses, re-create the object right before you need it, not at the start. For server-side apps, set the RPC timeout to match your longest operation — but that's a band-aid; the real fix is to not hold pointers across idle periods.

Note for bug hunters: This error often masquerades as a permissions problem because it surfaces after a timeout. Always check the System event log on the server for RPC or DCOM warnings around the timestamp of the failure. You'll see Event ID 10010 — that's your breadcrumb.