STATUS_INVALID_GROUP_ATTRIBUTES 0xC00000A4 Fix

You're seeing 0xC00000A4 when Windows tries to set group attributes on a file or service. It's almost always an ACL, SID, or service logon rights problem.

You know that moment when a service refuses to start and Event Viewer spits out 0xC00000A4? Or you run a script that sets permissions and it dies with STATUS_INVALID_GROUP_ATTRIBUTES? I had a client last month whose backup service died at 2am with this exact code. Their Monday morning was not pleasant. Another time it was a scheduled task that had a stale SID from a deleted admin account.

The trigger is almost always one of three things: setting permissions on a file or folder, starting or configuring a Windows service, or applying a Group Policy that touches security descriptors. Windows tries to attach a group to a security descriptor and the group is either missing, invalid, or the caller doesn't have the right privilege to set it.

What 0xC00000A4 Actually Means

In plain English, Windows tried to set the group attribute on a security descriptor and the group's Security Identifier (SID) wasn't valid for that context. A security descriptor has an owner, a group, a DACL, and a SACL. The group field says which group owns this object for POSIX-style semantics. Normally it's unused on Windows, but plenty of APIs and services still try to set it.

You get STATUS_INVALID_GROUP_ATTRIBUTES when:

The SID points to a group that no longer exists in AD or in the local SAM.
The SID is a well-known SID that can't be assigned as a group (like a user SID or a logon session SID).
The token you're running under lacks SeSecurityPrivilege or SeRestorePrivilege.
The AD group has a broken groupType or missing primaryGroupToken.
You're trying to set a group from a different domain with no trust.

The most common real-world cause I see: someone deleted a domain group in Active Directory, but the group SID is still baked into an ACL or service configuration on a member server. The service account tries to set that group at startup and boom, 0xC00000A4.

The Fix — Step by Step

Find the offending object. Where is the error coming from? If it's a service, open Event Viewer and look at the Application log around the failure timestamp. If it's a script or app, check its log. You need to know whether it's a file ACL, a service, or a GPO.
For services: open an elevated command prompt and dump the service's SID configuration.
```
sc qc YourServiceName
sc showsid YourServiceName
```
Look at the service SID and the account it runs as. If the account is a domain account that's been deleted, that's your problem. Recreate the account, or switch the service to a built-in account like NT AUTHORITY\LocalService.
For files and folders: use icacls to dump the ACL and look for orphaned SIDs (they show as raw S-1-5-21-... strings).
```
icacls "C:\Path\To\Folder" /save perms.txt /t /c
```
Then clean them up. The safest move is to reset inheritance and reapply known-good permissions:
```
icacls "C:\Path\To\Folder" /reset /t /c /q
icacls "C:\Path\To\Folder" /grant "BUILTIN\Administrators:(OI)(CI)F" /t
```
If a specific SID is stuck, remove it explicitly with icacls "path" /remove:g S-1-5-21-xxxx.
For GPO or AD-related errors: on a domain controller, check the group's groupType attribute with ADSI Edit or PowerShell.
```
Get-ADGroup -Identity "GroupName" -Properties groupType, primaryGroupToken
```
If groupType is -2147483646 (built-in local) or a weird value, the group is in a bad state. A group with -2147483640 (universal security) or -2147483644 (global security) is normal. Broken values usually come from an interrupted schema operation or a bad restore.
Check your privileges. If the app runs as a service or scheduled task, it needs the right token privileges. A low-privilege account can't set the group field on a security descriptor even if the group is valid. Run the same operation as a domain admin once to confirm. If it works elevated, the fix is SeSecurityPrivilege or SeRestorePrivilege via Local Security Policy (secpol.msc → Local Policies → User Rights Assignment).
Reboot and retest. Group membership and token privileges don't always refresh cleanly. A reboot after fixing the SID or ACL is faster than chasing ghosts.

If It Still Fails

Check these next:

SIDHistory. If a user or group was migrated from another domain and has an old SID in sIDHistory, some APIs choke on it. Look with Get-ADUser -Filter * -Properties sIDHistory | Where {$_.sIDHistory}.
Domain trust. If the group is from a trusted domain, verify the trust is healthy with nltest /sc_verify:OTHERDOMAIN. A broken trust returns this error because the SID can't be resolved.
Corrupt profile or token. Log in as a different admin and see if the error follows the object or the user. If it follows the user, delete and rebuild the profile.
Antivirus or EDR. Some endpoint agents hook NtSetSecurityObject and reject group changes they don't understand. Temporarily disable and retest. I've seen this twice with older CrowdStrike and SentinelOne builds.
Group Policy refresh. Run gpupdate /force and check gpresult /h report.html for failed GPOs referencing security settings.

If you've checked all of that and it still spits out 0xC00000A4, grab a Process Monitor trace filtered to SetSecurity operations. That'll show you exactly which process, which object, and which SID is failing. Nine times out of ten, once you see that line, the answer is obvious.