Fix COMADMIN_E_NOSERVERSHARE (0x8011041B) Error

I know seeing 0x8011041B pop up in Component Services can be a real head-scratcher. Let's get this fixed — it usually means COM+ can't find its partition share. Here's the direct fix that works for most admins.

One quick warning: this fix requires restarting the COM+ services, so it'll drop any active COM+ applications for a few seconds. Plan for a brief outage.

The Fast Fix: Recreate the COM+ Partition Share

Open Component Services (run comexp.msc as admin).
Expand Component Services → Computers → My Computer.
Right-click COM+ Partitions and select Properties.
In the Partition Content tab, look for any partitions. You'll probably see one named something like "Default Partition" or your app's partition.
If there's a partition, delete it (right-click → Delete). Don't worry — we'll recreate it.
Close Component Services.
Open an elevated Command Prompt (right-click CMD → Run as administrator).
Type this and press Enter:
```
net stop comsysapp /y
```
After a moment you should see: The COM+ System Application service was stopped successfully.
Now restart the service:
```
net start comsysapp
```
Expect: The COM+ System Application service is starting... started successfully.
Reopen Component Services.
Right-click COM+ Partitions → New → Partition.
Name it whatever you need (e.g., "Default Partition") and click OK.
Reboot the server for good measure — sometimes COM+ caches the old share path and a reboot clears it.

After the reboot, try your COM+ application again. The error should be gone. If it's not, move on to the variations below.

Why This Works

COM+ uses a hidden share called COM+ Partition (or something similar) under the hood. When the partition gets corrupted or the share gets manually deleted (which happens more than you'd think), COM+ can't find it. Deleting and recreating the partition forces COM+ to rebuild that share with the correct permissions for the local SYSTEM account. Restarting the COM+ services flushes any stale references. It's a brute-force reset, but it's reliable.

Less Common Variations of the Same Issue

1. Missing Hidden Share Manually Deleted

Sometimes an overzealous cleanup script or a rookie admin deletes the COM+ partition share. If you suspect this, check for it:

Open a Command Prompt as admin.
Run net share and look for anything with "COM+" in the name.
If it's missing, run net share COM+_Partition=C:\Windows\System32\Com\Partitions (adjust the path if your COM+ partition is elsewhere).
Then restart comsysapp as described above.

2. Corrupted COM+ Catalog

If the partition recreation still gives you the error, the COM+ catalog itself might be damaged. Here's the fix:

Stop the COM+ System Application service again.
Back up the catalog folder: %windir%\system32\com\catalog (just rename it to catalog_old).
Restart the comsysapp service. It'll create a fresh catalog.
Recreate your COM+ partitions and applications from scratch (yes, it's a pain, but it works).

3. Permission Issues on the Share Path

The SYSTEM account needs full control over the partition folder. To check:

Open File Explorer and go to C:\Windows\System32\Com\Partitions (or wherever your partition is stored).
Right-click the folder → Properties → Security tab.
Make sure SYSTEM has Full control. If not, add it.
Apply the changes, then restart comsysapp.

Prevention: Keep It From Happening Again

Don't mess with hidden shares. If you see something called COM+ Partition in net share, leave it alone.
Document your COM+ partitions. If you ever need to rebuild, knowing the names and settings saves time.
Set up alerts for Event ID 1066 in the System log — that's the event that fires when COM+ can't reach its share. Catch it early.
Back up the COM+ catalog regularly. Use the COM+ Backup utility or just script a copy of %windir%\system32\com\catalog.

That's it. The 0x8011041B error is annoying but it's almost always the share path. Recreate the partition, restart the service, and you're back in business. If you hit a blocker, drop me a comment and I'll help you dig deeper.