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
regsvr32on a DLL that registers COM+ components, you're bypassing the SDK. Use the proper installers or script viaCOMAdmin.COMAdminCataloginstead.
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.