Fix 0x8001012B: CO_E_NETACCESSAPIFAILED Error

When This Error Shows Up

You’re running a legacy application — maybe an old accounting system or a shared printer driver from 2010 — and suddenly you get: CO_E_NETACCESSAPIFAILED (0x8001012B). The exact words say something like “Either NetAccessDel or NetAccessAdd returned an error code.” I saw this last month on a Windows 10 Pro machine trying to connect to a network printer shared from a Windows Server 2008 box. Clicks fine in the UI, but the app bombs out with this hex code.

Root Cause

Under the hood, COM+ tries to call NetAccessAdd or NetAccessDel to manage network share access for DCOM objects. These are older Windows NT networking APIs that have been deprecated since Vista. On modern Windows 10/11, they often fail because the security context is wrong — either the COM caller doesn’t have permission to enumerate or modify network shares, or the target share isn’t accessible. In my client’s case, the DCOM launch user didn’t have “Access this computer from the network” rights.

Fix It – Step by Step

Check DCOM Permissions
Press Win + R, type dcomcnfg, and hit Enter. Expand Component Services > Computers > My Computer > DCOM Config. Find the problematic application (look for its CLSID or name). Right-click > Properties > Security tab. Under “Launch and Activation Permissions”, click Edit. Add NETWORK SERVICE and LOCAL SERVICE with Allow for all launch permissions. Also check “Access Permissions” – add Everyone with Allow for Local Access.
Verify Network Share Access
Open File Explorer and navigate to the network path the app is trying to use. If you get an access denied, fix the share permissions on the server. On the server, right-click the share folder > Properties > Sharing > Permissions. Give Everyone Read (or Full Control if required). Then go to Security tab and confirm the same.
Enable Legacy NetAPI Fallback
If the app still fails, you might need to force the legacy NetAPI behavior. Open Registry Editor (regedit) as admin. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. Create a new DWORD (32-bit) named EnableDCOM with value 1 if not present. Also check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters – set NullSessionPipes to include the pipe name the app uses (often NETLOGON or samr). Reboot after these.
Run the App as Admin
Right-click the application executable > Properties > Compatibility tab > Check “Run this program as an administrator”. This bypasses some permission issues.

Still Failing? Check This

If it’s still broken, fire up Event Viewer (eventvwr) and look under Windows Logs > System or Application for error ID 10016 (DCOM) or 7036 (service failures). That’ll point to the specific CLSID. Also test the app on a different network – I’ve seen domain group policy block these APIs. If all else fails, run dcomcnfg again, find the app, and set the Identity tab to “The interactive user” instead of “The launching user”. That’s the nuclear option, but it works.

Last note: if you’re on Windows 11 22H2 or later, Microsoft tightened DCOM security. You might need to add the app’s CLSID to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat key with a DWORD ActivationOverride set to 1. That’s a deep fix, but it saved me twice now.