Fix ERROR_INVALID_PRIMARY_GROUP (0X0000051C) Fast

Yeah, this one's a pain. You try to log in or run something as a domain user, and Windows throws ERROR_INVALID_PRIMARY_GROUP (0X0000051C) — basically saying, "This SID cannot be assigned as the primary group of an object." It usually pops up when you're dealing with a user who was moved between OUs or had their group membership changed in Active Directory. Let's fix it.

The Fix: Clear the Bogus SID in the Registry

The core issue is that Windows cached a bad primary group SID for that user. The quickest way out is to delete that cached SID from the registry. Here's the step-by-step — don't skip any of these.

1. Log in as a local admin. You can't fix this while logged in as the broken user. If you don't have another admin account, boot into Safe Mode with Networking (press F8 during startup, choose that option).
2. Press Windows key + R, type regedit, hit Enter. Click Yes when UAC asks.
3. Go to this key:
   

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

   You'll see a list of SID-named subkeys (like S-1-5-21-...).
4. Click each SID key. On the right side, look for ProfileImagePath. That tells you which user profile it belongs to. Find the one for the user getting the error.
5. With that user's SID key selected, look for a value named PrimaryGroupSid. If you see it, right-click it and choose Delete. If you don't see it, check the State value — if it's 0 (meaning the profile is loaded), change it to 1 (temporary profile).
6. Close Regedit. Restart the computer.
7. Have the user log in again. Windows should rebuild the primary group SID from Active Directory on the spot.

After the restart: The user logs in without the error. Their desktop and settings should be intact. If their start menu looks fresh, their profile got corrupted — you'll need to back up their data and delete their profile entirely (via Advanced System Settings > User Profiles > Settings).

Why That Fix Works

The primary group SID is a required part of every user's security token. In a domain, it's almost always set to S-1-5-21-...-513 (Domain Users). When that SID gets mangled — say, after a domain migration tool ran mid-session, or an admin manually changed a user's primary group in AD to something that doesn't exist locally — Windows can't map it to a real group on the machine. By deleting the cached PrimaryGroupSid, you force Windows to re-query Active Directory for the correct value at next logon. The registry is just a cache; the real source of truth is in AD.

Less Common Variations of the Same Issue

Sometimes the registry fix isn't enough. Here are the other flavors I've seen:

• Domain controller side: The user's primary group in AD got set to a group that no longer exists (like a deleted security group). Check the user's primaryGroupID attribute using AD Users and Computers or PowerShell (Get-ADUser -Identity username -Properties primaryGroupID). If it's 0 or points to a dead group, set it back to 513 (Domain Users) using Set-ADUser -Identity username -Replace @{primaryGroupID=513}.
• Local group policy conflict: A GPO forcing a custom primary group assignment can cause this. Run gpresult /h gp.html and look for a policy under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment named "Set primary group for users." If it's set to a specific group that's not Domain Users, that policy is the culprit. Remove the assignment and run gpupdate /force.
• Corrupted user profile: If the registry fix works but the user keeps getting the error after a few logins, the profile itself is toast. Create a new profile — rename the old C:\Users\username folder to .old, delete the registry SID key from ProfileList, and have the user log in fresh.

Prevention: Stop It From Happening Again

You don't want to chase this every week. Here's what I tell my team:

• Never manually change a user's primary group in AD unless you absolutely have to (and you almost never do). Leave it as Domain Users (513). If you need a user to have different group behavior, use secondary groups.
• Before running domain migration tools (like ADMT), snapshot the user's current primaryGroupID. After migration, verify it's still 513. Migration tools sometimes bungle this attribute.
• Keep an eye on GPOs that touch user rights. If you're adding custom primary group assignments, test them on a single user first. One wrong GPO can break a dozen logins.
• Use PowerShell to audit once a week: Get-ADUser -Filter * -Properties primaryGroupID | Where-Object {$_.primaryGroupID -ne 513} | Select-Object Name, primaryGroupID. That'll flag any accounts with non-standard settings before they cause logon failures.

That's the whole playbook. Start with the registry fix — it's fast and safe. If it doesn't stick, move to the AD side. Either way, you're out of that error in under 15 minutes.