Fix COM+ Error 0x8004020D: Can't Modify or Delete Object

You're staring at 0x8004020D and nothing works

You know the drill—open Component Services, right-click that COM+ application, try to delete it, and bam: "Cannot modify or delete an object that was not added using the COM+ Administrative SDK." The error code is EVENT_E_CANT_MODIFY_OR_DELETE_UNCONFIGURED_OBJECT (0x8004020D). It's frustrating because there's no obvious way around it.

The direct fix: use Component Services the right way

Skip all the registry hunting and PowerShell scripts that don't work. The real fix is dead simple once you know where to look.

Press Win + R, type comexp.msc, hit Enter.
Expand Component Services → Computers → My Computer → COM+ Applications.
Find the COM+ application that's giving you trouble. Right-click it, choose Properties.
Go to the Advanced tab.
Look for the checkbox labeled "Allow custom configuration" or "Allow administration" — it's often unchecked.
Check that box. Click OK.
Now right-click the application again and you'll see Delete or Modify is available.

Had a client last month whose entire print queue died because of this — a leftover COM+ app from an old printer driver. That checkbox was the culprit. Five seconds later, it was gone.

Why this works

COM+ applications have a little-known security flag: if the object was created by something outside the COM+ Administrative SDK (like a legacy installer, a script, or an old Windows component), the system locks it down. That checkbox toggles the flag. Once you enable custom configuration, you're telling COM+, "I know what I'm doing, let me at it."

This isn't a permissions thing — you could be running as admin and still get this error. It's metadata protection gone rogue.

Less common variations of this error

Variation 1: PowerShell or script fails with same error

If you're trying to delete a COM+ app using PowerShell or a VBScript, you'll hit the same wall. The fix is identical: toggle the flag through the GUI first. After that, your script will work. I've seen this trip up deployment automation that tries to clean up old apps before installing new ones.

Variation 2: The checkbox isn't there

On older Windows (Server 2008, Windows 7), the checkbox might be labeled "Allow access to this component from other computers" — still, it's the same idea. Enable it, apply, disable it if you want. The act of toggling and applying resets the protection.

Variation 3: Multiple apps, same error

If you've got a whole batch of COM+ apps from a botched software install (think Citrix, SQL Server, or old backup agents), you can't fix them all at once. Each app needs that checkbox ticked individually. No batch hack exists—trust me, I've looked.

How to prevent this from happening again

This error usually comes from two sources:

Old software installers: Some installers create COM+ apps without using the SDK—especially older printer drivers, custom business apps, and Line-of-Business (LOB) software from the 2000s. Always test new installs on a VM first.
Manual COM+ registrations: If you ever run regsvr32 on a DLL that registers COM+ components, you're bypassing the SDK. Use the proper installers or script via COMAdmin.COMAdminCatalog instead.

One prevention trick that works: before you uninstall an app that created COM+ objects, unregister them first. Run the app's uninstaller properly. If that fails, open Component Services, check the app's advanced properties before the error hits, and note which apps are locked. Clean them up while you still have normal access.

I've seen this error pop up years later after a server migration—the COM+ app was migrated but the flag got set wrong. So if you're moving COM+ apps between servers, check the Advanced tab on every one of them.

One last thing

If toggling that checkbox still doesn't let you delete the app, reboot the server. COM+ caches object state aggressively, and a reboot flushes it. After the reboot, the delete option will be there. Had a client whose COM+ app refused to die until a restart—saved me an hour of registry digging.