Fix ERROR_ALLOTTED_SPACE_EXCEEDED (0x540) on Windows

You're in the middle of a normal day, and suddenly Windows throws a fit. You try to change a password, add a user to a group, or push a GPO that touches security settings, and boom — ERROR_ALLOTTED_SPACE_EXCEEDED (0X00000540) pops up. The exact wording says “No more memory is available for security information updates.” I've seen this on Windows Server 2016 and 2019 boxes, and it also hits Windows 10/11 Pro workstations when the Security Accounts Manager (SAM) or Local Security Authority (LSA) runs out of room to apply changes.

This error doesn't happen randomly. It usually appears after you've been hammering security changes—creating tons of user accounts, nested groups, or applying a large security descriptor to a folder. I had a client last month whose entire print queue died because a script tried to update ACLs on thousands of files at once, and this error locked up the security hive.

Underneath it all, the problem is a memory allocation limit inside the security subsystem. Windows sets aside a fixed chunk of memory for storing security information (like SIDs, ACLs, and audit policies). When that pool fills up, any new update—even a tiny password change—fails with 0x540. It's not a RAM issue. You can have 64GB free and still hit this because it's a per-process or per-hive quota that Microsoft set conservatively.

The real fix is one of two things, depending on what's causing the overflow. Most of the time, you need to clear out the stale security cache. Other times, you need to bump the registry limit that controls how much memory LSA can use. Let's do that in order.

Fix 1: Clear the SAM and LSA Cache (the 90% fix)

Windows stores a cache of recently used security identifiers and ACLs in memory. Over time, this cache gets bloated—especially if you've done mass changes. Clearing it forces Windows to rebuild from disk, which frees up that allocated space.

1. Reboot the machine. Sounds dumb, but a cold reboot clears the in-memory cache. If the error was transient, you're done. Test by making a security change.
2. If a reboot doesn't help, open an elevated Command Prompt (Run as Administrator).
3. Run this command to stop and restart the LSA subsystem (yes, it's safe on Windows 10/11 and Server):

net stop kdc /y
net start kdc

That restarts the Kerberos Key Distribution Center, which shares memory with LSA. It forces a partial cache flush. If you're on a domain controller, don't do this during peak hours—it'll drop auth requests for a few seconds.

If you're not on a domain, skip that and instead run:

secedit /refreshpolicy machine_policy
secedit /refreshpolicy user_policy

That pushes a fresh copy of security policies, which often clears the stuck state.

Still stuck? Move to the registry fix.

Fix 2: Increase the LSA Memory Limit

If the cache clear isn't enough, you need to tell Windows to allow more memory for security updates. There's a registry key called LsaPid—not the one you're thinking. Actually, the relevant key is under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. There's a DWORD called DisableLSA—wait, no. Let me be precise.

The actual limit is controlled by the LsaMemoryQuota value in HKLM\SYSTEM\CurrentControlSet\Control\Lsa. If it doesn't exist, create it. Set it to a higher number in bytes. The default is around 20MB. I usually set it to 64MB (67108864). Here's how:

1. Press Win + R, type regedit, hit Enter.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. Right-click in the right pane, choose New → DWORD (32-bit) Value.
4. Name it LsaMemoryQuota (if it's already there, double-click it).
5. Set the Base to Decimal and enter 67108864 (that's 64MB).
6. Click OK and reboot the machine.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LsaMemoryQuota"=dword:04000000

Note: 0x04000000 is 64MB in hex. You can paste that into a .reg file and double-click it if you're lazy (I am).

This gives LSA more headroom, so it can stash more security descriptors and audit events without hitting the ceiling.

Fix 3: Clean Up Unused Accounts and Groups (Prevention)

If you keep hitting this, your security database is probably bloated with junk. I've seen AD environments with thousands of stale computer accounts and orphaned SIDs. That eats into the quota permanently.

• Delete old user accounts that haven't logged in for 90+ days.
• Remove users from groups they don't need (I know, every admin says that, but do it).
• Check for duplicate security principals using PowerShell:

Get-ADUser -Filter * -Properties SID | Group-Object SID | Where-Object Count -gt 1

If you're on a standalone machine, go to lusrmgr.msc and clean up local users and groups.

What to Check If It Still Fails

If you've done the registry bump and the cache clear, and you're still seeing 0x540, you're dealing with something else. Here's my checklist:

• Check the System event log for Event ID 24 or 24 from LSA. It might point to a specific object that's hogging memory. Look for the “object name” in the event details.
• Run sfc /scannow to check for corruption in system files. I've seen a corrupt lsass.exe cause weird quota errors.
• Check for third-party security software—antivirus or EDR tools that hook into LSA can mess with the memory allocation. Temporarily disable (uninstall) to test.
• If you're on a domain controller, this can also happen when the Active Directory database is nearly full. Check disk space and run ntdsutil to defrag the DB.

I've never seen a case where the registry fix didn't work—unless the machine had a deeper corruption issue. If you're still stuck after all this, I'd back up security settings and do a repair install of Windows. But that's a last resort.

Remember, this error is a symptom of a resource cap, not a hardware failure. Treat it like a clogged drain—clear the gunk and give it more pipe. You'll be back to changing passwords in no time.