SCARD_E_FILE_NOT_FOUND 0x80100024 — Smart Card Fix

Smart card returns SCARD_E_FILE_NOT_FOUND when the reader can't find the file the app asked for. Usually a wrong AID, stale middleware, or card profile mismatch.

You plug in the smart card, Windows sees the reader, the certificate even shows up in the store — then some app throws SCARD_E_FILE_NOT_FOUND (0x80100024). The card isn't dead. The reader isn't broken. What's actually happening is that the software asked the card for a file or application ID (AID) that doesn't exist on that specific card, and the card told Windows to go away politely.

This surfaces most often with government ID cards (CAC, PIV, eIDAS), banking cards used with a middleware like ActivClient or Charismathics, and corporate badge readers running Windows 10 22H2 or Windows 11 23H2. It also pops up after you swap cards in the same reader — the session from the previous card lingers and the new card gets queried with the old card's AID.

Work down this list. Stop when things start working.

Fix 1: Reseat the card and restart the Smart Card service (30 seconds)

Stale sessions are the single dumbest cause of 0x80100024, and the fix costs you nothing.

Pull the card out of the reader. Wait five seconds. Put it back in.
Open an elevated PowerShell and run:

Restart-Service SCardSvr -Force
Restart-Service ScDeviceEnum -Force

SCardSvr is the Smart Card resource manager. Restarting it drops every cached card handle, which forces the next app to establish a fresh session and re-read the AID list from the card itself. ScDeviceEnum handles plug-and-play for card readers — worth restarting alongside SCardSvr when a USB reader has been moved between ports.

If the error came back immediately with the same card, the problem is on the card or in the app's config, not the service layer. Keep going.

Fix 2: Verify the card actually has the file the app is asking for (5 minutes)

You need to see what's on the card. Two tools do this cleanly: CertUtil for anything certificate-related, and OpenSC's pkcs11-tool (or the middleware vendor's own diagnostic) for raw APDU work.

First, confirm Windows sees the card at all:

certutil -scinfo

That dumps the reader name, ATR, and any certificates the card exposes through the Microsoft minidriver. If it returns an ATR and no certificates, the minidriver isn't matching the card — that's your real problem, and it explains why an app then fails with 0x80100024 when it goes looking for a file.

Next, list the applications on the card. With OpenSC installed:

pkcs11-tool --list-slots
pkcs11-tool --list-objects --login

The --list-slots output shows the AID the middleware is presenting. Compare that to what the failing app requests. Common mismatches:

PIV vs. CAC AID. PIV is A000000308000010000100. CAC is A00000007901 and its variants. If your app hardcodes one and the card speaks the other, you get 0x80100024.
DOD vs. civil agency. Federal CACs sometimes present a different AID after a re-issuance. Middleware that was installed two years ago doesn't know about it.
Bank card SIM toolkit files. Some banking middleware expects EF files under a specific DF (dedicated file) that only exists on certain card generations.

If the AID the app wants isn't in that list, no amount of Windows fiddling will fix it. The card is what it is. You either reconfigure the app or reissue the card with the right profile.

Fix 3: Rebuild the middleware stack and clear the certificate cache (15+ minutes)

If the AID is on the card but the error persists, the middleware is lying about its cache. This is common with ActivClient, SafeNet Authentication Client, and old Gemalto Classic Client installs — they cache the card's file tree on first read and never invalidate it when the card is swapped or re-personalized.

Step 1: Nuke the middleware cache

Paths vary by vendor, but these are the usual suspects on Windows 10/11:

%ProgramData%\ActivIdentity\
%ProgramData%\SafeNet\
%AppData%\Gemalto\
%LocalAppData%\Microsoft\Crypto\PCPKSP\
%AppData%\Microsoft\Crypto\Certificates\

Back them up first, then delete the contents. The PCPKSP folder in particular holds per-card key container metadata — if it's stale, apps get told a file exists that doesn't, or vice versa.

Step 2: Re-register the minidriver

If you're on a Microsoft minidriver-based card (most PIV and CAC cards are), reinstall the base CSP:

certutil -csp "Microsoft Base Smart Card Crypto Provider" -repairstore My

Then reboot. Don't skip the reboot — the minidriver registers itself at boot, and re-registering without restarting leaves the old handle in place.

Step 3: Test with a known-good app before the problem app

Before you retry the original application, open certutil -scinfo again and confirm certificates are listed. If they are, open the Windows certificate manager (certmgr.msc), look under Personal > Certificates, and confirm the smart card cert is there with a valid private key reference. If the cert is missing but certutil -scinfo sees it, the problem is user profile corruption — log in as a different user and see if the app works. That tells you whether to rebuild the profile or keep chasing the card.

When none of this works

Two scenarios remain. First: the card itself is corrupted or was personalized with a non-standard profile. Only the issuing authority can fix that — send it back. Second: the application is broken and hardcodes a file path that no longer exists in the current card spec. Check the vendor's release notes for the card generation you're on. Government CACs had a major AID change in 2019 that broke a lot of Java-based middleware, and banking chip cards rotate AIDs every few years.

One more thing worth knowing: 0x80100024 is not a Windows error in the usual sense. It's a direct pass-through of the ISO 7816 status word 6A82 (file not found), wrapped into an HRESULT by the Smart Card subsystem. Once you know that, you can search card vendor documentation for 6A82 instead of the Windows code — the card vendor docs almost always use the raw status word, and you'll find answers faster.