SCARD_E_NO_MEMORY 0x80100006 Fix for Windows

SCARD_E_NO_MEMORY means the smart card resource manager ran out of memory. Usually it's a stuck service, a leaked handle, or a bad reader driver — not actual RAM.

Quick answer

Restart the Smart Card service (SCardSvr) and its dependency, plug the reader into a different USB port, and if it's a VPN or CAC/PIV environment, reboot the machine before you do anything else — the resource manager almost always holds leaked handles.

What's actually going on

SCARD_E_NO_MEMORY shows up when the Smart Card Resource Manager (SCardSvr) can't allocate an internal buffer or handle for a card transaction. Nine times out of ten it has nothing to do with your physical RAM. Your box could have 32GB free and you'll still see 0x80100006. The culprit is almost always a leaked context handle inside SCardSvr, a broken reader driver that keeps failing mid-transaction, or a third-party app (ActivClient, IDProtect, some VPN clients) that hammered the API and never released handles.

I've seen this blow up on Dell Latitude 5400s with the Broadcom 5880 reader after a Windows 10 21H2 update, and again on HP EliteBook 840 G8s running Windows 11 22H2 with the Realtek reader when the vendor driver version drifted. Both cases: the service accumulated thousands of leaked contexts over a 3-day uptime and then folded. A reboot clears it. The permanent fix is updating or rolling back the reader driver.

Fix it — numbered steps

Reboot first. Sounds lazy. It isn't. A reboot flushes the SCardSvr handle table entirely. If the error comes back within a day, keep reading — you've got a driver or app leak.
Check the service is actually running and not wedged. Open an elevated command prompt:
```
sc query SCardSvr
sc query ScDeviceEnum
sc query SCardSvr
```
If State says anything other than RUNNING, restart it:
```
net stop SCardSvr && net start SCardSvr
```
If it refuses to stop, kill it from Task Manager (services.exe child), then start it back up. Don't skip the dependency services.
Reseat the reader on a different USB controller. Not a different port on the same hub — a different physical controller. Front-panel USB usually hangs off a separate header than rear I/O on desktops. On laptops, unplug any USB hub between reader and machine. Docking stations are notorious for this; the DisplayLink USB layer drops card transactions and SCardSvr retries until it runs out of buffers.
Update or roll back the reader driver. Device Manager, find the Smart card reader, check the driver version. Compare it against the vendor's latest. If the error started right after a Windows cumulative update, roll back:
```
pnputil /enum-drivers | findstr /i "smartcard"
```
Then in Device Manager, right-click reader > Properties > Driver > Roll Back Driver. Reboot. Test.
Clear stale certificate and card state. If you're on a CAC/PIV setup, kill the middleware before restarting the service. ActivClient, IDProtect, and OpenSC hold exclusive handles:
```
taskkill /f /im activclient.exe
taskkill /f /im idprotect.exe
net stop SCardSvr
net start SCardSvr
```
Then reinsert the card.
Test with a known-good tool. Certutil is the cleanest test because it talks straight to the base CSP:
```
certutil -scinfo
```
If certutil also throws 0x80100006, the problem is below the app layer — service or driver. If certutil works but your VPN app doesn't, the app is the leaker.

If that doesn't clear it

You're probably looking at a genuine handle leak in a long-running process. Open Process Explorer (Sysinternals), find SCardSvr.exe, and check the Handles column over time. If it's climbing by hundreds per minute, something is calling SCardEstablishContext and never calling SCardReleaseContext. That's an app bug, not a Windows bug.

Other things worth trying:

Reinstall the Windows Smart Card components. In an elevated PowerShell:
Get-WindowsCapability -Online | Where-Object Name -like '*SmartCard*'
Remove and re-add the SmartCard-Reader capability.
Check for group policy that restricts SCardSvr memory or context limits. Rare, but I've seen it in hardened federal builds.
If it's a virtual desktop (Citrix, VMware Horizon), the USB redirection layer is your problem. Disable USB redirection for that device class and let the local machine handle it.
Registry check for a bad CSP entry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\Readers
Stale entries pointing at uninstalled middleware cause repeated failed loads that chew through the handle table.

Preventing it next time

Pin your reader driver version. Don't let Windows Update auto-replace a working Broadcom or Realtek reader driver with whatever ships in the next cumulative. Set the reader's driver policy to block automatic updates in Device Installation Settings, and keep the last-known-good INF on hand. Also schedule a weekly reboot on any machine doing heavy smart card work — CAC users, DoD contractors, anyone running continuous PIV auth. A 168-hour uptime limit on SCardSvr kills 90% of recurrences before users see them.

If you're in a federal or contractor environment and this keeps hitting the same model, it's not random. It's the driver. Escalate to your endpoint team with the reader model, driver version, and uptime at failure. They can push a version pin via SCCM or Intune in an afternoon.