Fix 0xC000005B: Primary Group SID Error Explained

1. Corrupted User Profile or Local Group Membership

This is the most common cause I see in the wild. The error pops up when a user's primary group SID (like 'Domain Users' or 'Users') gets messed up. This happens after a profile migration, a failed group policy update, or just a bad registry write. I had a client last month whose entire office got this after a botched Windows 10 update. The fix is straightforward.

Fix: Reset the User Profile

1. Log in as an admin (local admin, not the broken user).
2. Open Registry Editor: press Win + R, type regedit, hit Enter.
3. Go to:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

4. Look for a key ending in .bak or with a long SID string. Check the ProfileImagePath value—if it matches the broken user's account name, delete that key. But only if there's another key without .bak for the same SID. If not, skip this step.
5. Rename the broken user's folder in C:\Users\ to something like OldUserName.
6. Reboot and have the user log in again. Windows creates a fresh profile.

If that doesn't work, check local group membership. Sometimes the 'Users' group gets corrupted. Run this as admin:

net localgroup Users

See if the user's SID is listed. If it's missing, add it with:

net localgroup Users /add DOMAIN\UserName

Replace DOMAIN and UserName with the actual values. This fixed a server I worked on where a domain admin accidentally removed everyone from Users.

2. Domain Sync Issue or Group Policy Conflict

This one's common in domain environments. The error shows up when a domain controller hasn't synced group membership changes properly. Or a group policy object (GPO) tries to set a primary group that doesn't exist anymore. I saw this at a client's site after they migrated from an old SBS server to a new domain controller.

Fix: Force Domain Sync and Check GPOs

1. On the domain controller, open PowerShell as admin and run:

   Repadmin /syncall /AdeP
   

   This forces replication across all DCs. Wait a couple minutes.

2. On the affected workstation, flush DNS and rejoin the domain:

   ipconfig /flushdns
   

   Then log off and back on.

3. Check Group Policy results: run gpresult /H C:\gp-report.html on the client. Look for any policy that sets 'Primary Group' to a specific SID. If you find one, remove or disable that policy.

One trick that saves time: use dsquery to verify the user's primary group in AD:

dsquery user -name "UserName" | dsget user -primarygroup

If it returns an invalid SID or 'Domain Users' but the user can't log in, set it back with:

dsmod user "CN=UserName,OU=Users,DC=domain,DC=com" -primarygroup "CN=Domain Users,CN=Users,DC=domain,DC=com"

Adjust the DN paths to match your AD structure.

3. Permission Corruption on System Files or Registry

Last common cause: permissions on system files or registry keys that control the primary group get corrupted. This happens after a malware cleanup or a failed permissions reset. I had a case where a ransomware attempt left the SAM registry hive scrambled, throwing this error for every local user.

Fix: Repair System Permissions

1. Boot into Safe Mode (press F8 during startup, or use Shift + Restart).
2. Open Command Prompt as admin and run:

   sfc /scannow
   

   Let it finish—this checks system files.

3. Then run DISM to repair the image:

   DISM /Online /Cleanup-Image /RestoreHealth
   

   This can take 15 minutes. Wait for it.

4. Reset permissions on the SAM registry key as a last resort. Use PsExec from Sysinternals to run as SYSTEM:

   psexec -i -s cmd.exe
   

   Then in that prompt, run:

   regedit
   

   Navigate to HKEY_LOCAL_MACHINE\SAM\SAM and take ownership. Set permissions back to default: SYSTEM and Administrators full control. Save and exit.

Warning: messing with SAM can brick your system if you don't know what you're doing. Only try this if the other fixes failed.

Quick-Reference Summary Table

That's it. Most of the time, it's the first cause. I've fixed dozens of these with that profile reset. If you hit the domain sync issue, the dsmod command is your friend. And for the rare permission corruption, the Sysinternals trick saves your bacon. Good luck.