0X80090300

SEC_E_INSUFFICIENT_MEMORY (0X80090300) Fix – Real Causes That Work

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

This error means Windows ran out of memory for security tokens. Usually a corrupted LSASS cache or a bad RDP config. Here's what actually fixes it.

1. Corrupted Local Security Authority (LSASS) Cache – The Most Common Cause

I've seen this exact error on maybe twenty machines over the last two years. Every single time the owner thought they needed to buy more RAM. They didn't. The actual problem is the Local Security Authority Subsystem Service (LSASS) has a cache of Kerberos tickets and security tokens that gets corrupted. Usually happens after a failed domain join attempt, a bad VPN disconnect, or a messy Windows update.

One client had it happen after his kid's Minecraft mod crashed his laptop. Another time it was a remote desktop session that froze mid-authentication. The LSASS process holds onto broken tokens, runs out of its internal memory pool, and throws 0x80090300.

The fix: Clear the Kerberos ticket cache and reset LSASS's internal state. You don't need to reboot unless I tell you. Open Command Prompt as Administrator and run these two commands:

klist purge
klist -li 0x3e7 purge

The first one clears your user tickets. The second clears the system-wide LSA tickets (that's the magic one). Wait ten seconds, then try whatever gave you the error again. I've fixed RDP connections, file share access, and Outlook authentication with just that.

If the error comes back after a few hours, you need to flush the entire LSASS token store. Run this in an elevated PowerShell:

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

Wait. That will kill LSASS and crash your system. Do not run it unless you're ready for a reboot. It forces LSASS to rebuild its entire token cache on next boot. I only do it when the klist commands don't stick. After reboot, the error should be gone.

2. Schannel / TLS Certificate Store Corruption

Second most common cause I see is a corrupted Schannel certificate store. Schannel is the component that handles TLS/SSL on Windows. When it can't allocate memory for a certificate chain verification, it throws 0x80090300. This happens most often when you're connecting to a web server, a VPN, or an RDP gateway that uses smart card authentication.

I had a client last month whose entire print queue died because of this. Their print server used TLS to communicate with the printer, and the certificate store had a bad entry from a failed certificate renewal. Every print job that hit the Schannel check threw the error.

Fix it by rebuilding the certificate store:

  1. Open certlm.msc (Computer Certificates) as Administrator.
  2. Expand Personal and Trusted Root Certification Authorities.
  3. Look for certificates with a red X or that show as corrupted (they'll have a weird expiration date like 1/1/1601). Delete any you find.
  4. Close the console, then run this command to force a certificate store rebuild:
certutil -store -user My | findstr /i "sha1"

That doesn't do the rebuild directly, but it forces certutil to enumerate the store. If there's corruption, it'll log a detailed error in the Application event log under source Schannel. Check that log with Event Viewer (eventvwr.msc), look for Event ID 36888 or 36874. That tells you which certificate thumbprint is broken.

Once you've deleted the bad certificate from both Personal and Trusted Root stores, run gpupdate /force to reapply group policy certificates if you're domain-joined. Then reboot. The error should be gone.

3. Memory Quota for LSASS Too Low (RDP / Remote Desktop Specific)

If you get 0x80090300 specifically when connecting via Remote Desktop, especially to a server with many concurrent sessions, the problem is almost always the memory quota for LSASS. Windows sets a default limit on how much memory LSASS can use for cached credentials and tokens. When that limit is hit, new connections fail with this exact error.

I fixed this for a law firm's terminal server that had 40+ concurrent users. Every morning at 9 AM, the error would start popping up for anyone trying to connect. The fix was increasing the LSA memory quota.

Here's how:

  1. Open Group Policy Editor (gpedit.msc) on the server.
  2. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
  3. Find Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication — no, that's not the right one. Actually, the setting you want is Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. Skip that too. The real one is hidden under Administrative Templates > System > Kerberos:
Computer Configuration -> Administrative Templates -> System -> Kerberos -> Set maximum Kerberos ticket cache size

Enable it and set the value to 102400 (that's 100 MB instead of the default 20 MB). This gives LSASS more room for cached tokens.

If you can't use group policy (standalone machine), use the registry directly:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Create a DWORD named: MaxTicketCacheSize
Value: 102400 (decimal)

Reboot for the change to take effect. After that, RDP connections should stop hitting the memory ceiling.

One more thing: if you're on Windows 10/11 and this happens after a feature update, Schannel's memory management sometimes gets a bug. Run sfc /scannow and dism /online /cleanup-image /restorehealth to rule out system file corruption. I've seen that fix it for two clients whose error appeared right after the 23H2 update.

Quick Reference Summary

Cause Fixes When It Applies
Corrupted LSASS cache klist purge then klist -li 0x3e7 purge; if recurring, kill LSASS (reboot required) After failed logins, domain join issues, broken VPN disconnects
Schannel certificate store corruption Delete bad certs in certlm.msc, check Event ID 36888/36874, run gpupdate /force TLS/SSL connections, smart card auth, RDP gateways
Low LSASS memory quota for RDP Increase MaxTicketCacheSize to 102400 via GP or registry, reboot RDP to servers with many concurrent sessions, especially at peak times

Was this solution helpful?