CO_E_ACNOTINITIALIZED 0x8001013F: Real Fix for COM IAccessControl

You're staring at CO_E_ACNOTINITIALIZED (0x8001013F) and the message "The COM IAccessControl object is not initialized". This usually hits when you're launching a legacy app or a custom script that calls a COM component. I've seen it most often after a Windows 10/11 feature update, or when someone's been tinkering with DCOM permissions. Also pops up in Office add-ins and PowerShell scripts that instantiate COM objects directly.

What's actually going on?

Under the hood, COM tries to check security permissions on the object you're calling. To do that, it needs an IAccessControl interface. That interface should be properly initialized by the COM runtime. When it's not, you get this error. The root cause is almost always one of three things:

1. The COM component is registered incorrectly (registry entries got mangled).
2. The .NET Framework's COM interop layer is corrupted or missing a patch.
3. DCOM permissions for the user or group are wrong — the user account doesn't have the right to access the object's security descriptor.

The "not initialized" part is the giveaway. It's not that the object is missing — it's that COM can't even get to the security check. So don't go hunting for a missing DLL. That's a red herring.

The fix that works 90% of the time

First, try re-registering the components. This is the fastest and most common fix. Open an elevated Command Prompt (right-click, Run as administrator). Then run these:

regsvr32 /i vbscript.dll
regsvr32 /i jscript.dll
regsvr32 /i ole32.dll
regsvr32 /i oleaut32.dll

Reboot. If the error's gone, you're done. If not, move to repairing .NET Framework. This is the second most common fix. Microsoft's .NET repair tool is your friend here:

3. Grab the .NET Framework Repair Tool from Microsoft (I usually just search for ".NET Framework Repair Tool" — it's a small download).
4. Run it and let it do its thing. It'll ask for a restart. Do it.

This handles most corrupted interop issues. If you're on Windows 10 1809 or later, you might also want to enable the .NET Framework 3.5 feature if your app needs it. Go to Control Panel > Programs > Turn Windows features on or off, tick .NET Framework 3.5 (includes .NET 2.0 and 3.0), and let it install. I've seen this fix COM issues that weren't even related to .NET — it's weird but true.

Check DCOM permissions

If the above didn't help, you're likely dealing with a permissions problem. Here's how to sort that out:

1. Open dcomcnfg (press Win+R, type it, hit Enter).
2. Expand Component Services > Computers > My Computer > DCOM Config.
3. Find the component that's failing. You might have to search for it — the name isn't always obvious. Look for anything related to your app's vendor or the CLSID from the error details.
4. Right-click it, select Properties, go to the Security tab.
5. Under Launch and Activation Permissions, check who's allowed. Add Everyone or Users with Local Launch and Local Activation if it's missing. That's usually enough.
6. Also check Configuration Permissions — make sure the user has Read.

Be careful with this. Don't go granting Everyone full control across all components. You're just fixing the one that's broken.

Still failing? Here's the last resort.

If you've re-registered, repaired .NET, and checked DCOM perms, the culprit is often a broken COM+ catalog. This happens after system restore or aggressive registry cleaning. Run this in an elevated command prompt:

regsvr32 /u comadmin.dll
regsvr32 comadmin.dll

Then restart. If that still doesn't do it, you're looking at a deeper system corruption. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. But honestly, I've rarely had to go that far with this specific error.

One more thing — if this is happening in a script or app you're writing, you might be calling the COM object before the runtime is fully initialized. In that case, the fix is in your code, not the system. Initialize COM explicitly with CoInitialize or CoInitializeEx before you create the object. But that's a developer issue. If you're a sysadmin debugging someone else's app, stick to the steps above.