First Thing: Run as Administrator
This error screams permissions. I've seen it a hundred times on Windows Server 2016 and 2019. You're probably installing a COM+ component from a command prompt that isn't elevated. That's the #1 trigger. Right-click Command Prompt or PowerShell and pick Run as administrator. Then try the install again. 30 seconds, costs you nothing, fixes a good 40% of these.
If that didn't do it, don't waste time rebooting. Move on.
Moderate: Re-register the DLL Manually
Sometimes the COM+ installer can't call DllRegisterServer because the DLL is already in a broken state. Force it with regsvr32. This is my go-to after the admin check.
- Open an elevated command prompt.
- Run:
regsvr32 /i "C:\path\to\your\component.dll" - If it succeeds, you'll see a popup. If it fails, you'll get a different error code — that tells you the DLL itself is the problem, not COM+.
If regsvr32 fails with 0x80029C4A or similar, the DLL is likely missing dependencies. Run dumpbin /dependents if you have Visual Studio tools, or just make sure all the VC++ runtimes are installed. On Server Core, you might need to install the Desktop Experience feature — I've seen that bite people running Server Core where DLL dependencies are missing.
Advanced: Check Component Services Permissions
Still stuck? Then it's the COM+ application identity or the user account doesn't have the right to modify the registry. The culprit here is almost always the account running the install — it needs Impersonate a client after authentication and Replace a process level token rights. Those are default on Administrators, but if you're using a service account, it might not have them.
Open Component Services (dcomcnfg.exe), go to Component Services > Computers > My Computer > COM+ Applications. Find the application you're trying to install into. Right-click, select Properties, then the Identity tab. Make sure it's set to a user that has the required privileges. I usually set it to Interactive User for testing, but for production, create a dedicated account and grant it the rights via Local Security Policy.
Also, check the Security tab on the same properties page. The Launch and Activation Permissions need to include the installing account. Default is often Everyone for launch, but activation can be restricted. Add your account with Local Activation and Local Launch checks.
While you're there, look at the Advanced tab. If you're running 64-bit Windows and the component is 32-bit, you might need to check Enable 32-bit applications. That one's sneaky — the error message doesn't hint at it, but I've had it pop up on Server 2019 with old VB6 components.
Registry Permissions Fix
If the above still fails, the DLL registration is trying to write to HKCR or HKLM. COM+ impersonates the identity, and if that account can't write to those keys, you get 0x8011041A.
Check the DACL on:
HKLM\SOFTWARE\Classes\CLSIDRight-click, Permissions, and make sure the installing account has Full Control (at least during install). I've seen security baselines strip these down. Grant it, try again, then lock it back if you want.
When Nothing Else Works
If you've done all this and it still fails, the problem is the DLL itself. Check the event log — look for Application errors right around the timestamp. Sometimes there's a missing dependency that only shows up in the trace. Use Process Monitor to see what registry keys it's trying to write. That'll point you straight to the exact key that's failing.
One last thing: don't bother reinstalling the entire COM+ application unless you've done the above. I've seen people blow away their COM+ config and it doesn't help if the root cause is permissions. The real fix is usually the admin check or the regsvr32 step. Good luck.