Fix 0xC000012B STATUS_TOKEN_ALREADY_IN_USE on Windows

STATUS_TOKEN_ALREADY_IN_USE means a Windows service or app tried to reuse an active security token. Restart the service or run SFC/DISM. Here's the real fix.

Quick answer

Restart the service that's failing (usually the one in the event log) or reboot the machine; if that doesn't stick, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an elevated prompt.

What's actually happening here

This error is a NTSTATUS code that Windows throws when one process tries to set a token as the primary token for a thread or process, but that same token is already assigned to another active thread or process. In plain terms: the security token—the thing that carries your user's privileges and group memberships—is a single-use object when it comes to being primary. You can't have two threads running with the exact same token as primary.

You'll typically see this when a Windows service starts, or when a scheduled task tries to run with a specific user account. It's also common in third-party backup or anti-virus software that impersonates a user token to access files. The error shows up in the System event log with source Service Control Manager or in the Application log, often as a startup failure. I've seen it most on Windows 10 21H2 and Windows Server 2019 after a service crashes and tries to restart too quickly—the old token hasn't been fully released before the new attempt.

The reason step 1 works is that a reboot or service restart forces Windows to dump every token in the system and rebuild them cleanly. If the race condition (old thread still dying, new service starting) was the cause, that clears it.

Numbered fix steps

Identify the culprit service. Open Event Viewer (eventvwr.msc), go to Windows Logs > System, and look for an Error event that mentions STATUS_TOKEN_ALREADY_IN_USE or the hex code. The source will name the service. If it's vague, check Windows Logs > Application for the same code—third-party apps log there.
Restart the service. Open an elevated Command Prompt (Win+X, then “Terminal (Admin)”). Replace SERVICE_NAME with the actual service name from step 1:
```
net stop SERVICE_NAME
net start SERVICE_NAME
```
If it starts without error, you're done—the token was stuck. If it fails, move on.
Reboot the machine. This is not a cop-out. A full restart releases all handles, including tokens that are orphaned by a crashed process. You'd be surprised how often this is the only fix needed.
Run SFC and DISM. Corrupted system files can break the token-creation logic itself. At an elevated prompt:
```
sfc /scannow
```
Then:
```
DISM /Online /Cleanup-Image /RestoreHealth
```
Let DISM finish completely—it can take 15 minutes on a slow disk. Then reboot and test the service again.
Check for conflicting software. If the error happens on a service that uses impersonation (like IIS AppPool or a scheduled task), look at any recently installed anti-virus or security tool. Some of them hook into the token APIs and hold references longer than they should. Temporarily disable the tool (not just real-time protection—disable the whole service) and see if the error goes away.

If the main fix fails

Sometimes the service won't start even after a reboot. That points to a corrupted service configuration or a bug in the software itself.

Re-register the service. For a custom service, uninstall and reinstall it. For built-in services, try sfc /scannow again—it often restores service registrations.
Check group policy. The token may be failing because the account that the service runs under is missing the Replace a process level token privilege. Open gpedit.msc, go to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, and add the service account to Replace a process level token. This is a common miss on domain controllers.
Use Process Monitor. If you're truly stuck, run Process Monitor while the service starts. Filter by Result = ACCESS DENIED or TOKEN in the path. This gives you the actual handle that's failing. It's overkill for most, but when you're at this point, you need data.

Prevention tip

Don't configure services to restart indefinitely on failure. If a service crashes and the restart policy kicks in within seconds, you'll hit this race condition. Set the restart delay to at least 30 seconds in the service recovery options. That gives the old threads time to die and release their tokens. I've also seen this happen when two scheduled tasks run at the exact same moment with the same user account—stagger their start times by a minute.

One more thing: if you're on Windows Server and use service accounts like gMSA, verify that the account's msDS-ManagedPassword attribute isn't corrupted in Active Directory. A bad password can cause a token to be created but never properly linked, which shows up as this exact error on the next attempt.