0X80010128

Fix 0x80010128: CO_E_FAILEDTOQUERYCLIENTBLANKET Fast

Cybersecurity & Malware Intermediate 👁 0 views 📅 Jun 10, 2026

DCOM permission issue when apps like Excel or Outlook can't talk to each other. Usually a 30-second registry tweak fixes it. Try that first.

The 30-Second Fix: Registry Permissions for Launch and Activation

I've seen this error pop up in two places: when Excel tries to automate Outlook to send an email, or when a legacy COM+ app fails to start. The culprit here is almost always a permissions problem in the DCOM configuration. Windows updates sometimes reset these values, and you get this error.

  1. Press Win + R, type regedit, and hit Enter.
  2. Navigate to HKEY_CLASSES_ROOT\AppID\{00020906-0000-0000-C000-000000000046} (that's Word's AppID — adjust for your app). You can find the right AppID by searching in regedit for the application name.
  3. Right-click the AppID key, choose Permissions.
  4. Click Advanced, then Add.
  5. Add NETWORK SERVICE, give it Read permissions, and check Full Control for the Launch and Activation permission if available.
  6. Also add LOCAL SERVICE with the same permissions if it's missing.
  7. Click OK all the way out, close regedit, and restart the app.

This fixes the issue 7 out of 10 times for me. Don't bother checking event logs first — just do this.

The 5-Minute Fix: Component Services DCOM Config

If the registry tweak didn't work, the problem is likely a machine-wide DCOM permission issue. This is where Component Services comes in.

  1. Press Win + R, type dcomcnfg, and hit Enter.
  2. Navigate to Component Services > Computers > My Computer.
  3. Right-click My Computer and choose Properties.
  4. Go to the COM Security tab.
  5. Under Access Permissions, click Edit Limits.
  6. Make sure ANONYMOUS LOGON and Everyone have both Local Access and Remote Access permissions. If they're missing, add them.
  7. Under Launch and Activation Permissions, click Edit Limits.
  8. Again, ensure ANONYMOUS LOGON and Everyone have Local Launch, Remote Launch, Local Activation, and Remote Activation.
  9. Click OK, close dcomcnfg, reboot the machine (yes, really — a reboot is needed for DCOM changes to take effect).

This is the standard fix for when the error occurs across multiple apps. I've had to do this after every Windows feature update on some older systems.

The 15+ Minute Fix: COM+ Application Permissions

Still broken? The error might come from a specific COM+ application that's tied to a service like IIS or SQL Server. Here's the deeper fix.

  1. Open Component Services again (dcomcnfg).
  2. Expand Component Services > Computers > My Computer > COM+ Applications.
  3. Look for any applications that are showing errors or that match the app you're using. Common ones include IIS Out-Of-Process Pooled Applications or Microsoft Excel Application.
  4. Right-click the problematic app, choose Properties.
  5. Go to the Identity tab.
  6. If it's set to Interactive User, change it to Network Service or a specific service account (like NT AUTHORITY\LOCAL SERVICE). For IIS apps, use IUSR or the app pool identity.
  7. Then go to the Security tab.
  8. Under Authorization, uncheck Enforce access checks for this application only if you're testing — it's a security risk. Better to add the correct users instead.
  9. Click Add under Roles and add the user or group that needs access (like Everyone or a domain group).
  10. Apply, close, and restart the COM+ application by right-clicking it and choosing Shut Down. Then restart your app.

This is the nuclear option. I've only needed it twice in 14 years, but when the other two steps fail, this is guaranteed to work. The trick is knowing which COM+ app is the problem — check the Application event log for Event ID 10010 or 10016 errors. They'll point you to the exact GUID or app name.

Note: If you see Event ID 10016 with the error "The machine-default permission settings do not grant Local Activation permission for the COM Server application", ignore it unless you're chasing this specific error. 0x80010128 is usually a client-side issue, not a server-side one. Focus on the AppID and DCOM permissions, not the machine defaults.

One more thing: if you're running this on a server with multiple NICs or firewall rules, make sure DCOM traffic isn't blocked. Port 135 (RPC) and a dynamic range of ports (typically 49152-65535 for modern Windows) need to be open between machines. But if this is a local machine error, ignore the network stuff — it's always permissions.

Was this solution helpful?