STATUS_CANNOT_IMPERSONATE (0xC000010D) fix

I know this error is infuriating—you're trying to run a service or an app, and Windows slaps you with STATUS_CANNOT_IMPERSONATE (0xC000010D). It feels like a security guard who won't let you through, even with the right badge.

Let's get to the fix. You're here for answers, not a lecture.

Quick fix: service logon account

Nine times out of ten, this error happens when a service is trying to impersonate a user but can't. The most common trigger: you changed a service to run under a specific domain user account, but that account doesn't have the SeImpersonatePrivilege right. Here's what to do:

1. Press Win + R, type services.msc, and hit Enter.
2. Find the service that's failing. Right-click it, choose Properties.
3. Go to the Log On tab. Switch from This account to Local System account (or Network Service if the service needs network access).
4. Click Apply, then OK.
5. Restart the service. Right-click the service, choose Restart.

This works because Local System and Network Service already have impersonation privileges. If you absolutely need a specific user account, keep reading—we'll grant that privilege manually.

Why did that work?

The error code 0xC000010D translates to STATUS_CANNOT_IMPERSONATE. Impersonation is Windows's way of letting one process act as another user. Services running under Local System are part of the operating system's security context—they get the high-level SeImpersonatePrivilege by default. When you switch to a domain account, that privilege isn't automatically assigned, so the impersonation call fails with this exact error.

Think of it like a hotel key card: Local System has a master key; a domain account gets a guest key that only works in certain rooms. If you try to open the manager's office with a guest key, the door locks—same idea.

Still stuck? Grant SeImpersonatePrivilege manually

If you must use a specific user account (maybe for database access or file shares), you need to grant that account the right to impersonate. Here's how on Windows 10/11 Pro, Enterprise, or Server:

1. Open Local Security Policy (type secpol.msc in Run).
2. Go to Local Policies → User Rights Assignment.
3. Double-click Impersonate a client after authentication.
4. Click Add User or Group, type the user account name (e.g., DOMAIN\ServiceAccount), and click OK.
5. Close the policy window and restart the service.

Note: This policy change might take a few minutes to propagate in a domain environment. You can force it with gpupdate /force in Command Prompt (run as admin).

If you're on Windows 10/11 Home, you won't have secpol.msc. In that case, your only realistic option is to run the service as Local System or Network Service, unless you're comfortable editing the registry directly. I don't recommend that for Home users—it's easy to break something.

Less common triggers

I've seen this error pop up in two other scenarios:

• Kerberos delegation failures in enterprise apps (like SQL Server Reporting Services or SharePoint). If the service account isn't trusted for delegation in Active Directory, you get this error. Fix: ask your domain admin to set the account as Trusted for Kerberos Delegation in AD Users and Computers.
• Antivirus or security software blocking impersonation. Some aggressive endpoint protection (like CrowdStrike or McAfee) can prevent services from switching user contexts. Try temporarily disabling the AV (disconnect from the network first if you're worried) and see if the error stops. If it does, add an exception for the service executable.

Prevention tips

You don't want to deal with this again. Here's how to avoid it:

• Use Managed Service Accounts (MSA) if you're on a domain. They're designed for services and automatically get the right privileges. Create one with New-ADServiceAccount in PowerShell, then assign it to the service in the Log On tab.
• Never run services under a user's personal account. It's a security nightmare and a common cause of impersonation errors when that user's password changes.
• Test impersonation early. When you're setting up a new service, try the Local System account first. If it works, then switch to a specific account—and verify the privilege assignment before you go live.

That's it. You've got the fix, the reasoning, and the edge cases. Go ahead and restart that service—it should stay running now.