Fix STATUS_AGENTS_EXHAUSTED (0xC0000085) on Windows

0xC0000085 means Windows ran out of authority agent values for a security identifier. Usually caused by a leak in a service or app. Fix it by restarting the offending service or rebooting.

Quick answer: 0xC0000085 is a resource exhaustion error — the Local Security Authority (LSA) has used up all available authority agent values for a given identifier authority. Reboot, or restart the service that's leaking SIDs.

What's actually happening here is subtler than the message suggests. Windows assigns each security principal a SID, and the SID's prefix encodes an identifier authority (NT Authority, Local Authority, etc.). Each identifier authority has a finite pool of agent values it can hand out as sub-authorities. When something — a service, a driver, a badly written app — keeps calling LsaCreateTrustedDomainEx or similar APIs and never releases the agent values, the pool drains. Once it's empty, the next allocation returns STATUS_AGENTS_EXHAUSTED and whatever operation was in flight fails. You'll see it in Event Viewer under LSA, or as a hard stop during a domain join, Group Policy refresh, or credential validation on member servers.

This isn't a bug you patch. It's a leak, and the leak is in whatever's calling the LSA APIs in a loop. Microsoft's own lsass has a known path where a misbehaving third-party credential provider (VPN clients, SSO agents, older antivirus filter drivers) exhausts the pool on machines that stay up for weeks. I've hit it twice on Server 2016 boxes running a specific Fortinet SSO agent that never released trust handles after a DC failover.

Step-by-step fix

Confirm it's actually 0xC0000085. Don't trust the popup. Open Event Viewer → Windows Logs → System and filter for Source LsaSrv or Security. Look for Event ID 6038 or 40960 with the NTSTATUS code in the body. If you don't see the code there, you're chasing a different failure.
Reboot the machine. I know. It feels like giving up. But the agent pool resets on LSA restart, and on a member server that's been up 40+ days, a reboot buys you a clean baseline and tells you whether this is a one-off or a chronic leak. If it comes back within days, it's a leak and you keep going.
Identify the leaking process. After the reboot, before you do anything else, snapshot the LSA state:
```
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='LsaSrv'} -MaxEvents 50 | Format-List TimeCreated, Message
```
Then watch for the first 0xC0000085 recurrence and correlate the timestamp against running services. The offender is almost always a service that starts at boot and does authentication work — credential providers, EDR agents, backup agents that authenticate to a share on a schedule.
Stop and disable the suspect service. Once you've got a name, set it to Disabled, reboot, and watch for 48 hours. If the error doesn't come back, you've found it. Check the vendor for an update — this is a known class of bug in older builds of several enterprise agents.
Check LSA Protection and Credential Guard. On Server 2019/2022 and Win10 1809+, LSA Protection (RunAsPPL) can interact badly with unsigned filter drivers that hook LSA. Verify:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL
```
If it's 0x1 and you're running an old third-party credential provider, temporarily set it to 0x0, reboot, and see if the exhaustion stops. Don't leave it off permanently — that's a security regression.

If that doesn't work

Two less common causes worth ruling out. First, an actual SID pool problem from over-provisioned local accounts. If something has created tens of thousands of local users (yes, this happens with bad automation), you can hit the per-authority limit legitimately. Check with:

Get-LocalUser | Measure-Object

Anything north of a few thousand local accounts on a member server is a red flag.

Second, a corrupted LSA database. This is rare but real. Rebuild it by booting into WinRE and running esentutl /p %windir%\security\database\secedit.sdb against the offline hive. Back up first. This is a last resort — I've seen it fix exactly one case out of maybe thirty.

Prevention

Set a scheduled reboot on any server running third-party identity agents. I'm serious. A 30-day uptime cap inside a maintenance window prevents the majority of 0xC0000085 incidents, because the leak is slow and cumulative. Pair that with monitoring for LsaSrv Event ID 6038 — it fires before you hit the wall. Alert on it once and you'll never see the blue-screen version of this error again.