Fix Windows Error 0x00000545: ERROR_BAD_TOKEN_TYPE

Quick answer: ERROR_BAD_TOKEN_TYPE (0x00000545) means a process tried to use a token — usually a service account's logon token — in a way that token type doesn't allow, and the fix is almost always on the service account, not on the Windows install.

I've seen this error pop up most often on Windows Server 2019 and 2022 boxes running line-of-business services, but it also shows up on Windows 10 and 11 when someone tries runas with a weird account or when a scheduled task fires off with a mismatched logon type. The token Windows hands out at logon comes in flavors — primary, impersonation, restricted, identification. Each API that touches a token expects a specific flavor. When you hand it the wrong one, the kernel returns STATUS_BAD_TOKEN_TYPE, which surfaces to user mode as 0x00000545. It's not a virus. It's not a corrupted system file. It's a permissions-and-context problem, and treating it like a corrupted install will waste your afternoon.

Here's a concrete scenario I ran into last year: a client had a .NET service configured to log on as a domain service account, and someone in IT had recently locked down the account by removing it from the local Log on as a service right. The service would start, try to spawn a worker process under its own token, call CreateProcessAsUser, and instantly log 0x00000545. The service account technically authenticated, but the token it got was a network logon token that couldn't be used as a primary token for process creation. That's the classic shape of this error.

What you'll do first

Don't reinstall Windows. Don't run sfc /scannow and hope. Go straight to the service or task that's throwing the error and fix the account context. Here's the sequence that actually works.

Step 1: Find the failing process

1. Open Event Viewer (press Win+R, type eventvwr.msc, hit Enter).
2. In the left pane, expand Windows Logs and click Application.
3. Look for red error entries timestamped near when the failure happened. You want the source name — it'll be the service, app, or scheduled task that owns the problem.
4. If nothing useful is in Application, check System and also Applications and Services Logs > Microsoft > Windows > TaskScheduler and the specific service log if one exists.

After this step you should have the exact name of the service, executable, or task that's failing. Write it down. Everything below depends on that name.

Step 2: Check the logon account and its rights

1. Press Win+R, type services.msc, Enter.
2. Find the service from Step 1. Right-click it, choose Properties.
3. Click the Log On tab. Note the account — is it Local System, Network Service, a local user, or a domain account?
4. If it's a domain account, open an admin Command Prompt and run:

whoami /user /groups

:: For a domain service account named svc_app on domain CONTOSO:
net user svc_app /domain | findstr /i "logon"

:: See which accounts have the service logon right locally:
secedit /export /cfg %temp%\secpol.cfg
findstr /i "SeServiceLogonRight" %temp%\secpol.cfg

You should see the account listed under SeServiceLogonRight. If it isn't there, that's your bug. A domain account that hasn't been granted this right can still authenticate, but the resulting token isn't primary — it's a network or interactive logon token, and using it for process creation is exactly what triggers 0x00000545. If you see a blank or missing value after SeServiceLogonRight, that's the smoking gun.

Step 3: Grant the missing right

1. Press Win+R, type secpol.msc, Enter. (On a domain-joined server, you might prefer editing the GPO that owns this setting for the OU.)
2. Expand Local Policies > User Rights Assignment.
3. Double-click Log on as a service.
4. Click Add User or Group, type the service account name, click Check Names to confirm it resolves, then OK.
5. Click Apply, then OK. You should see the account now listed and the Apply button grayed out.

Reboot is usually not required, but restart the service so it re-authenticates. In services.msc, right-click the service and choose Restart. If it was stopped, choose Start. Watch the event log for five minutes — if 0x00000545 doesn't come back, you're done.

Step 4: Confirm the token type at runtime

If it's still failing, use Process Monitor from Sysinternals. Filter on the process name from Step 1 and on Operation is Process Create. You want to see what token the process is trying to use. Look for a CreateProcessAsUser call returning STATUS_BAD_TOKEN_TYPE. Also grab Process Explorer (procexp.exe), right-click the process, and check Properties > Security. A healthy service process shows a primary token. If you see Impersonation or Identification level in the token details, that confirms the wrong-token-type diagnosis.

If that didn't fix it

Try these in order. Stop as soon as one works.

• Switch the service to LocalSystem temporarily. If it starts and stays running under LocalSystem but fails under the service account, the problem is definitively the account's rights, not the binary. Don't leave it on LocalSystem long-term unless it's an internal-only service.
• Check the Scheduled Task settings. Open Task Scheduler, find the task, go to the General tab, and look at When running the task, use the following user account plus the Run whether user is logged on or not radio button. If it's set to Run only when user is logged on, the token type is different and won't support some actions. Switch to Run whether user is logged on or not and re-enter the password.
• Look for a restricted token from a parent process. Some security agents (CrowdStrike, Carbon Black, older Symantec Endpoint) inject into processes and hand out restricted tokens. If the service used to work and stopped after an agent update, that's your culprit. Test by temporarily stopping the agent (with vendor guidance — don't just kill it in production).
• Reset the service account password. In services.msc, Log On tab, retype the password and confirm. A stale password can produce 0x00000545 because Windows falls back to a cached token that doesn't have the right type.
• Check for a UAC or AppLocker interference. If an AppLocker policy denies the executable, the failure sometimes manifests as a bad token rather than a block message. Run gpresult /h C:\temp\rsop.html and skim the AppLocker section.

Prevention

Service accounts that get locked down by a well-meaning security team cause this error more than anything else. Whenever you change group membership or logon rights for a service account, restart every service that uses it and check the event log for thirty seconds. That habit alone prevents most 0x00000545 incidents.

Also document every service account in a spreadsheet with three columns: the account name, which services use it, and which logon rights it needs. When someone audits rights, you can prove what's required and stop them from removing Log on as a service "because nobody told us it was needed." Store that sheet in your ops wiki, not on someone's laptop.