Windows Error 0X0000055C: Built-In Group Fix

Cause #1: The Group Is Protected by the SAM Registry Key

I know this error is infuriating—you're just trying to remove a user from the Guests or Administrators group, and Windows slaps you with 0X0000055C. The most common reason: the Security Account Manager (SAM) in Windows marks built-in groups as protected. You can't delete or rename them through the normal GUI. This tripped me up the first time too.

Here's the fix that works 90% of the time: tweak the SAM's behavior via the registry. But be careful—this is the core of Windows security.

Step-by-Step Register Fix

1. Press Win + R, type regedit, and hit Enter. You'll need Admin privileges.
2. Navigate to:

   HKEY_LOCAL_MACHINE\SAM\SAM

   By default, you won't see the subkeys. Right-click the SAM key, select Permissions, then give your account Full Control. Apply, then close.
3. Now expand HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Groups. You'll see numeric entries like 00000220 (that's the Administrators group RID).
4. Find the RID for the group you're stuck on. Common ones:
   • Administrators: RID 0x220 (512 decimal)
   • Guests: RID 0x221 (513 decimal)
   • Users: RID 0x221 (514 decimal) — actually, wait, Users is 0x221 too? No, Users is 0x222. Double-check your own system using net localgroup in CMD.
5. Select the key for your group. In the right pane, double-click the C value (binary). Look at the second set of bytes—specifically, byte 0x38 (offset 56). If it's set to 02, the group is marked as special. Change that byte to 00. For example, if the C value starts with 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02, change the 02 to 00.
6. Click OK and close Regedit. Restart your PC. You should now be able to modify that group through lusrmgr.msc or net localgroup.

Warning: This is a nuclear option. If you remove the special flag from the Administrators group, you could break system integrity. Only do this for groups like Guests or Backup Operators that you own. I've seen people lock themselves out after removing the flag from Administrators. Don't be that person.

Cause #2: Group Policy Is Enforcing the Restriction

If the registry fix didn't help, Group Policy might be blocking changes. This is especially common on domain-joined machines or systems locked down by corporate IT. The policy Restrict these groups from being modified is often enabled.

Check and Fix Group Policy

1. Open the Group Policy Editor: Win + R, type gpedit.msc. (Not available on Windows Home—skip to the next fix if you're on Home.)
2. Navigate to:

   Computer Configuration → Windows Settings → Security Settings → Restricted Groups

3. Look for any entry that includes the group you're trying to modify (e.g., Guests). If it's there, right-click and Remove it. Then apply the change.
4. Run gpupdate /force in Command Prompt (Admin). Reboot.
5. Try your operation again. If it works, Group Policy was the culprit.

Real-world scenario I've seen: A Windows 10 Pro machine on a small business domain. The admin had locked down the Guests group via Restricted Groups to prevent a shared kiosk user from being added. Removing that policy freed it up.

Cause #3: The Group Is Being Used by a Running Service or Process

Sometimes the error is a red herring. Windows says it's a special group, but the real problem is that a service holds a security descriptor reference to that group. This happens with Remote Desktop Users or Performance Log Users groups when services like Remote Desktop Services (TermService) or Performance Logs & Alerts are running.

How to Diagnose and Fix

1. Open Services.msc. Look for services that use the group. For Remote Desktop Users, stop the Remote Desktop Services service (set it to manual if you want, but don't disable it unless you're sure).
2. For Performance Log Users, stop Performance Logs & Alerts.
3. After stopping, try modifying the group via lusrmgr.msc. If it works, restart the service.

Another trick: Use Handle.exe from Sysinternals. Run handle -a -u groupname (e.g., handle -a -u "Remote Desktop Users") to see which process has a handle to the group. Kill that process (or stop it gracefully) and try again.

Quick-Reference Summary Table