Fix 0XC0000125 STATUS_SPECIAL_GROUP on Windows 10/11

Quick Answer (for the impatient)

Remove the account from the special group (Backup Operators, Hyper-V Administrators, etc.) via lusrmgr.msc or net localgroup, then log off and back on. Or launch the program from a command prompt using runas /user:Administrator to bypass the restriction.

Why This Happens

You’re trying to run a program, and boom—Windows throws 0XC0000125, often with the text “STATUS_SPECIAL_GROUP.” This isn’t a corrupted file or a virus. It’s Windows telling you: “Your user account is in a special security group, and this program isn’t allowed to run under those conditions.”

The common triggers? You added your account to the Backup Operators group so you could back up files, or maybe you joined the Hyper-V Administrators group to manage VMs. Some enterprise apps and even older games check the group membership at launch and refuse to run if they detect a “privileged” group—Microsoft’s own credential guard and UIPI (User Interface Privilege Isolation) can also block certain processes when a token has elevated group SIDs.

This error code 0XC0000125 appears most often on Windows 10 versions 1809 through 22H2 and Windows 11 21H2 and 22H2. You’ll see it when double-clicking an .exe or when a scheduled task tries to start something. It’s not a crash—the app simply never starts.

Step-by-Step Fixes

Step 1: Identify the Special Group

1. Press Win + R, type lusrmgr.msc, hit Enter. (If on Windows 11 Home, you’ll need to use the command prompt method below.)
2. In the left pane, click Groups. Look for groups like Backup Operators, Hyper-V Administrators, Network Configuration Operators, Power Users, or Remote Desktop Users.
3. Double-click each of those groups and see if your username appears in the Members list. Write down which group(s) contain your account.

4. Expected outcome: You’ll see at least one special group listed with your username. If none, the error might be from a different cause—skip to the alternative fixes.

Step 2: Remove the Account from the Offending Group

1. In lusrmgr.msc, double-click the group (e.g., Backup Operators).
2. Select your username from the members list and click Remove. Confirm if prompted.
3. Click Apply, then OK.

4. Expected outcome: You should see “The user was removed successfully.” If you get an access denied error, you’re not running as an administrator—log in as a different admin account first.

Step 3: Log Off and Log Back On

This step is non-negotiable. The group membership change doesn’t take effect until your session token is refreshed. Press Ctrl + Alt + Delete, choose Sign out, then log back in with the same account.

Expected outcome: After logging back in, try launching the program that gave you 0XC0000125. It should run without error. If not, move to the alternative fixes.

Alternative Fixes (When the Main Fix Doesn’t Work)

Alternative 1: Use a Different User Account

If you need to keep the special group membership (say, you really need to be in Backup Operators for your backup software), create a second standard user account for day-to-day work. Make it a local account, no special groups. Run the problematic program from that account. It’s the cleanest fix and avoids touching your admin setup.

Alternative 2: Run the Program as a Different User

Open a command prompt as administrator. Type:
runas /user:Administrator "C:\Path\To\YourProgram.exe"
Replace Administrator with a local admin account that isn’t in any special group. You’ll be prompted for that account’s password. This bypasses the group check because it uses the other account’s token.

Expected outcome: The program should launch in a new window.

Alternative 3: Disable Credential Guard (If You Have It)

Some users on Windows 10 Enterprise or Education see this error because Credential Guard adds special group SIDs. To check if it’s enabled:

1. Open PowerShell as admin.
2. Run Get-ComputerInfo -Property "DeviceGuard*". Look for DeviceGuardSecurityServicesRunning—if it shows 1, Credential Guard is on.

3. To disable it temporarily: Open Group Policy Editor (gpedit.msc), go to Computer Configuration > Administrative Templates > System > Device Guard, set “Turn on Virtualization Based Security” to Disabled. Reboot.

   Expected outcome: After reboot, the error should stop. Keep in mind this reduces security—only do this if you understand the trade-off.

Alternative 4: Adjust the Registry (Advanced Users Only)

If you’re stuck and can’t change groups or accounts, you can block the specific group SID from being added to the token. This is risky—mess it up and you might lock yourself out.

1. Open Registry Editor (regedit) as admin.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. Create a new DWORD (32-bit) value named RestrictRemoteCli. Set its value to 1.
4. Reboot. Expected outcome: Some special group SIDs won’t be added to remote sessions, but this may not fix local app launches—it’s a long shot.

Prevention Tip

The best way to avoid 0XC0000125 is to never put your day-to-day user account into groups like Backup Operators or Hyper-V Administrators. Instead, create a separate admin account for group membership changes. Use a standard account for everything else—email, browsing, running apps. That way, special group restrictions only hit the admin account, and you can log into your normal account without any launch errors.

Also, if you’re joining a domain, talk to your IT department about whether those special groups are truly needed for your daily tasks. Many domain admins throw users into Backup Operators out of laziness—it’s rarely required for end users.

Still stuck? Check the Windows Event Viewer under Windows Logs > Application for event ID 1000 or 1001—they often contain the offending .exe path. Search that exe’s documentation for “special group” requirements.