STATUS_SMARTCARD_NO_KEY_CONTAINER (0XC0000384): Fix Missing Key Container

You're trying to badge in, Windows spits out 0xC0000384, and now you're locked out of your own desk. Annoying, I know. Let's fix it.

This error means Windows found your smart card, talked to the minidriver, and asked for the private key container that matches your certificate — and the card said "never heard of it." The container doesn't exist on the card, or Windows is looking at a stale reference. Either way, the login chain breaks and you get STATUS_SMARTCARD_NO_KEY_CONTAINER.

Step 1: Confirm the card is actually enumerating

1. Plug in the smart card reader. Watch the LED. It should blink once, then go steady.
2. Open an elevated Command Prompt (right-click Start, pick Terminal (Admin)).
3. Run:

certutil -scinfo

You should see the reader name, the card ATR, the card name (something like "Yubico PIV" or "Gemalto IDPrime"), and a list of certificates on the card. If certutil hangs or shows an empty certificate list, stop here. Your card isn't presenting its containers at all, and no amount of Windows-side fiddling will help. Replace the card or re-encode it at the issuing authority.

If you see certificates, keep going. The problem is on the Windows side.

Step 2: Nuke the stale certificate from the user store

Nine times out of ten, Windows cached a certificate that points to a container that no longer exists on the card. This happens when IT reissues the card but the old cert lingers in the user profile.

1. Press Win+R, type certmgr.msc, hit Enter.
2. Expand Personal > Certificates.
3. Look for any cert with the smart card icon next to it. Right-click and choose Delete. Confirm the prompt.
4. Also check Trusted Root Certification Authorities > Certificates for orphaned smart card root certs from an old vendor. Delete anything that doesn't match your current card.

After you click Delete, you should see the list refresh immediately. If the cert won't delete, it's been linked to a policy — jump to Step 5.

Step 3: Restart the Smart Card service

1. Back in the elevated Command Prompt, run:

net stop scardsvr
net start scardsvr

You should see "The Smart Card service was stopped successfully" followed by "started successfully." If the stop command fails because other services depend on it, run this first:

net stop certprop

Then restart scardsvr and finally net start certprop. The Certificate Propagation service is usually the one holding the lock.

Step 4: Remove and re-add the card in the minidriver

Windows keeps a per-card cache under the CSP (Cryptographic Service Provider). Clear it:

1. Close every app that touches certificates — Outlook, Teams, VPN clients, browsers.
2. Open Registry Editor (regedit).
3. Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\Readers

You'll see one subkey per reader. Rename each subkey by adding _old to the end — don't delete them yet, in case you need to roll back. Windows will rebuild them the next time a card is inserted.

Unplug the reader, wait five seconds, plug it back in. Open certutil -scinfo again. The card should enumerate cleanly and the error should be gone the next time you try to log in.

Why that worked

When you insert a smart card, Windows asks the minidriver for a list of key containers. Each container holds a private key tied to a public certificate. The error 0xC0000384 is STATUS_SMARTCARD_NO_KEY_CONTAINER, which literally means: the container Windows asked for isn't on the card.

That mismatch almost always comes from stale caching. The certificate in your user profile says "my key lives in container A." The card says "container A doesn't exist anymore, I'm container B now." Deleting the cert and the CSP cache forces both sides to renegotiate from scratch, and the container names line up again.

Less common variations

Virtual smart card (TPM) throwing 0xC0000384

If you're using a TPM-backed virtual smart card (common in Surface Pro 7+ fleet deployments), the "container" lives in the TPM, not on a physical chip. Fix it by clearing the TPM-aware certificate store:

certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" <container-name>

You can find the container name with certutil -key. Then reboot — the TPM will regenerate the container on next boot.

After a Windows feature update

Some 22H2 and 23H2 updates silently replaced the vendor minidriver with the inbox Microsoft one. If the error appeared right after Patch Tuesday, roll the minidriver back:

1. Device Manager > Smart card readers > right-click your reader.
2. Update driver > Browse my computer > Let me pick from a list.
3. Pick the vendor driver, not the Microsoft Generic one.

Roaming profile or FSLogix container

If your user profile roams, the Calais registry hive can replicate between machines and point at containers that exist on machine A but not machine B. Delete the user's cached profile folder on the affected machine and let it rebuild. FSLogix users: check C:\Users\<user>\AppData\Roaming\Microsoft\Crypto for stuck references.

Prevention

• Never reissue a smart card without clearing the old cert from the user's profile first. Ask your PKI admin to publish a revocation before the new card ships.
• Keep the vendor's minidriver updated. The inbox Microsoft driver works for basics but skips half the PIV container features.
• If you're on Windows 11 22H2 or later with a YubiKey 5 series, install Yubico's Smart Card Minidriver 4.6 or newer. Older versions had a container enumeration bug that triggers this exact error after the card sleeps.
• For shared workstations, clear the certificate cache between users. A one-line scheduled task running certutil -scinfo >nul at logoff keeps the container list fresh.

Locked out right now? Do Step 2 and Step 3 in that order. That clears 80% of these cases in under two minutes.