0X00000543

Fixing ERROR_CANT_OPEN_ANONYMOUS (0x543) on Windows

Cybersecurity & Malware Intermediate 👁 1 views 📅 May 28, 2026

You get this error when a process tries to open an anonymous security token and can't. It's almost always caused by a broken service or corrupt token handle.

When Does This Error Hit?

You'll see error code 0x00000543 (ERROR_CANT_OPEN_ANONYMOUS) when a process — usually running as SYSTEM — tries to open an anonymous-level security token and Windows slaps it down. I've dealt with this on a few client machines running Windows 10 Pro 21H2 and Windows Server 2022. The most common trigger: a scheduled task or a third-party service (like a backup agent or antivirus scanner) calling OpenProcessToken() with TOKEN_QUERY on a thread that's already running under an anonymous token. Another scenario: an RPC client that's impersonating a null session and then tries to duplicate that token. Classic case was a client's managed detection and response agent that kept crashing every 15 minutes until I found this.

Root Cause (Plain English)

Windows has these token levels: Anonymous, Identification, Impersonation, and Delegation. Anonymous is the lowest — it's basically a black box that says "I have no identity." When a process tries to open that token (not use it, but grab a handle to it), the system says "No. You can't open a handle to an anonymous token because that would leak kernel-mode security info." It's a safety lock. The error happens when something is doing something it shouldn't — like a service that tries to impersonate a user but fails and ends up with an anonymous token, then some other service tries to peek at it.

Fix Steps

Step 1: Identify the Culprit Process

First, find the process that's throwing this error. Open Event Viewer and go to Windows Logs > System. Look for Event ID 543 (or any error with source "Kernel-General" or "Microsoft-Windows-Security-Auditing"). The detail usually shows the process ID (PID).

  • Open Task Manager, go to Details tab, sort by PID.
  • Cross-reference that PID. Note its name and path.

I found the culprit was MsMpEng.exe on one machine — the Windows Defender antivirus engine. On another, it was svchost.exe running a broken RPC service.

Step 2: Check Service Dependencies

If the process is a service (most are), open Services.msc and find it. Right-click > Properties > Dependencies tab. Look for services that depend on it. If any of those are also failing, fix them first. Often, the real problem is a parent service like Remote Procedure Call (RPC) or Security Accounts Manager.

Step 3: Run an SFC Scan and DISM

Corrupt system files can break token operations. From an admin Command Prompt:

sfc /scannow

Then:

DISM /Online /Cleanup-Image /RestoreHealth

Reboot. If this doesn't fix it, move on.

Step 4: Reset the Token Handle (Advanced)

If you're comfortable with PowerShell, you can force a refresh of the token cache. This is my go-to when the error is from a specific session. Run PowerShell as admin:

Get-WmiObject Win32_Process -Filter "Name='yourProcess.exe'" | ForEach-Object { $_.Terminate() }

Replace yourProcess.exe with the actual process name. Then restart the service that owns it via Restart-Service -Name serviceName. This kills the bad token and forces a clean start.

Step 5: Disable Third-Party Security Software

Some security suites hook into token operations. Temporarily disable any third-party antivirus or endpoint protection (e.g., SentinelOne, CrowdStrike, Malwarebytes). If the error stops, update or reconfigure that software to allow token-level operations.

Still Failing? Check This

If the error persists, look deeper. Run Process Monitor from Sysinternals and filter for OpenProcessToken with result ACCESS DENIED. That'll show you the exact call stack. Also check if any group policies or security templates tightened the "Impersonate a client after authentication" user right — removing that from SYSTEM can cause this. And finally, if it's a service running under a domain account, verify that account isn't locked or expired. Had a client last month whose backup agent failed every morning because of a forgotten password change. Same error, different cause.

No point restarting the whole machine unless you've narrowed it down — that's just a band-aid. Track the process, fix the root cause, and you're done.

Was this solution helpful?