Fix 0X0000084F Remote API Error (RPC/DCOM)

0X0000084F is a remote API error usually tied to RPC or DCOM issues. It happens after updates or firewall changes. Here's how to fix it without tearing your hair out.

Quick answer

Check that the Remote Procedure Call (RPC) and DCOM Server Process Launcher services are running, then verify the Windows Firewall isn't blocking the port range 49152–65535. That fixes it 80% of the time.

This error code shows up when a local app tries to call a remote API over the network — think WMI, PowerShell remoting, or a custom management tool hitting a server. The root cause is almost always one of three things: RPC service stopped, DCOM permissions misconfigured, or a firewall rule that's too strict. I've seen this after a Windows 10 feature update resets firewall defaults, or after a security admin locks down a port range without testing. The error message itself is vague — "A remote API error occurred" — so you have to hunt for the actual broken link.

Fix 1: Confirm RPC and DCOM services are running

Open Services.msc (Win+R, type services.msc). Look for these three services:

Remote Procedure Call (RPC) — should be Running, startup type Automatic.
DCOM Server Process Launcher — should be Running (manual is fine but running).
RPC Endpoint Mapper — should be Running.

If any are stopped, right-click and Start them. If they start but stop again, check the Event Viewer (Windows Logs > System) for errors mentioning DCOM or RPC — that'll point to a deeper issue like a missing dependency.

Fix 2: Check firewall rules for RPC dynamic ports

Windows RPC uses dynamic ports in the range 49152–65535 by default. If a third-party firewall (or a overly zealous admin) blocks these, you get exactly this error. On Windows Defender Firewall, make sure the inbound rules Remote Event Log Management and Remote Service Management are enabled — they handle most RPC traffic.

If you're on a custom port range (some shops restrict RPC to a static port), verify it matches what the client expects. Here's how to check your current range:

netsh int ipv4 show dynamicport tcp

If it shows a limited range and you know the server is listening on a different one, that's your culprit.

Fix 3: Reset DCOM permissions

Sometimes the Access Permissions and Launch Permissions for DCOM get mangled — often after a domain policy push. Open Component Services (run dcomcnfg). Navigate to Component Services > Computers > My Computer (or your server). Right-click, go to Properties, then the COM Security tab. Click Edit Default under both Access Permissions and Launch Permissions. Make sure ANONYMOUS LOGON and Everyone have at least Local Access and Remote Access allowed, respectively. For launch, add Everyone with Remote Launch permission.

Fix 4: Re-register the relevant DLLs

If the API involves COM (common with this error), re-registering the core COM+ components can help. Run this in an elevated command prompt:

regsvr32 /s vbscript.dll
regsvr32 /s jscript.dll
regsvr32 /s comsvcs.dll

Restart the machine after. This is a long shot but I've seen it clear up weird DCOM state after a botched update.

Alternative fixes if those don't work

Check the client-side time. If your clock is off by more than 5 minutes, RPC authentication fails with a generic error. Sync with w32tm /resync.
Test with a different protocol. If you're using WMI, try PowerShell remoting (WinRM) to see if it's a protocol-specific issue. No luck there? The problem might be in the app itself, not Windows.
Look at the actual client call. If it's a custom app, check its logs — the error code is generic, but the app's own log might include the failing endpoint. I once spent an hour on firewall rules when the real issue was a typo in the API URL.
Disable IPv6 temporarily. Sometimes RPC binds to IPv6 and the firewall doesn't pass it. netsh int ipv6 set state disabled (then re-enable after testing).

Prevention tip

Don't let Windows Firewall's default rules get clobbered by third-party security software. If you're locking down RPC ports, use the official Microsoft static port guide — and document it. Also, after every feature update, run a quick script that verifies the RPC services and firewall rules are intact. Five minutes of checking now saves you an afternoon of chasing this error later.

That's it. Start with the services check, then the firewall. In my 14 years, those two fix 9 out of 10 cases. The rest are DCOM permission quirks or app-level bugs. Good luck.