Fix SCARD_E_READER_UNAVAILABLE (0x80100017) on Windows

Smart card reader throwing 0x80100017? Usually a dead Smart Card service or a reader that re-enumerated on a new COM port. Here's the fix that actually works.

Quick answer: Restart the Smart Card service (sc start scardsvr), then check Device Manager for a reader that re-enumerated on a different COM port. That combo fixes 8 out of 10 cases.

I know this error is infuriating, especially when you're staring at a DoD CAC, a bank PIV card, or a YubiKey that worked fine yesterday. SCARD_E_READER_UNAVAILABLE (0x80100017) means the Windows Smart Card Resource Manager asked the underlying reader driver to do something and got nothing back. The reader isn't there. Or Windows thinks it isn't. Nine times out of ten it's one of two things: the SCardSvr service crashed or got set to Disabled by a Group Policy push, or your USB reader re-enumerated on a new COM port and the app calling SCardConnect is still pointing at the old one.

It shows up constantly in enterprise environments. You push a driver update, someone reboots, and every badge reader on the floor stops answering. Or a laptop docks and re-docks and the reader ends up on COM5 instead of COM3. Certificate logins then fail with 0x80100017 and everyone blames the card.

Step-by-step fix

Confirm the reader is even detected. Plug it in and open Device Manager (devmgmt.msc). Look under Smart card readers. If nothing's there, or you see a yellow bang, this isn't a service problem — it's a driver or cable problem. Try a different USB port (rear ports on desktops, not a hub).
Check the Smart Card service. Open an elevated Command Prompt and run:
```
sc query SCardSvr
sc query ScDeviceEnum
sc qc SCardSvr
```
Both should show RUNNING and START_TYPE as AUTO or DEMAND. If SCardSvr is STOPPED or DISABLED, that's your culprit.
Start it manually.
```
sc config SCardSvr start= demand
sc start SCardSvr
sc start ScDeviceEnum
```
Note the space after start=. That trips people up constantly.
Verify what readers Windows actually sees. Run this and watch the output:
```
certutil -scinfo
```
If it lists your reader by name, the resource manager is fine and the problem is app-level. If it errors out with 0x80100017, the reader layer is broken.
For USB readers, force a fresh enumeration. Unplug the reader, then uninstall the device in Device Manager (check "Delete the driver software for this device" if it's a known-bad driver). Reboot. Plug the reader back in and let Windows reinstall it. This clears stale COM port assignments that cause most CCID reader failures.
Check for a stuck SCardSvr handle. If a service or app crashed while holding the reader, the resource manager can hang. Kill these processes in Task Manager: scardsvr.exe, CertPropSvc, and any app that touches cards (ActivClient, OpenSC, opensc-tool, browser cert dialogs). Then restart the service.
Confirm the reader driver. Microsoft's inbox CCID driver works for most readers. Third-party driver packages (Gemalto, Identiv, HID) sometimes ship a version that conflicts with the inbox one. In Device Manager, right-click the reader → Update driver → Browse → Let me pick → try Microsoft Usbccid Smartcard Reader (WUDF).

If that doesn't work

Try the CertPropSvc (Certificate Propagation) service next. It's usually set to Manual, and it depends on the reader being available. If it's crashing on startup, it takes SCardSvr with it. Set it to Automatic (Delayed Start) and reboot:

sc config CertPropSvc start= delayed-auto

If you're on a domain and the service keeps disabling itself after a reboot, Group Policy is winning. Check Computer Configuration → Windows Settings → Security Settings → System Services. A lot of hardened baselines (CIS, DISA STIG) disable SCardSvr unless you explicitly allow it. That's a common gotcha on freshly imaged workstations.

Registry side, verify these keys exist and aren't broken:

HKLM\SOFTWARE\Microsoft\Cryptography\Calais\Readers
HKLM\SYSTEM\CurrentControlSet\Services\SCardSvr

Missing or empty Readers subkeys after a driver uninstall will produce 0x80100017 even with the service running. A clean reinstall of the reader driver recreates them.

Last resort: run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. Corrupted winscard.dll or scardsvr.exe does happen after a bad cumulative update, and I've seen 22H2 updates break SCardSvr on a handful of machines.

Stop it from happening again

Don't rely on USB hubs for card readers, especially unpowered ones. The reader can brown out, drop off the bus, come back on a different port, and hold a stale handle. Plug readers directly into the machine. And if you're deploying via image, verify SCardSvr's startup type after your security baseline applies, not before. That's where the surprise 0x80100017 on Monday morning comes from.