On 10/01/2022 14:05, Werner Koch wrote: > On Fri, 7 Jan 2022 16:23, Marko Božiković said: > >> My scdaemon.conf has a single line: >> >> card-timeout 1 > > Please remove this at least for testing. > >> log-file <path to log file> >> debug-level basic >> verbose > > Please change the > > debug-level ... > > to > > debug ipc,app,cardio > > Actually you should have seen a debug line "Yubikey: config=" due to the > verbose option. The "cardio" above returns all commands (so-called > APDUs) send to the card. This should help to reveal the problem.
Just to confirm, my scdaemon.conf file should look like this: debug-level ipc,app,cardio verbose log-file <path to log file> >> 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation >> (0x8010000b) > > Some other process is accessing the Yubikey. But as you already know > > pcsc-shared Yeah, but that one is available in 2.3. The card-timeout was suggested some time ago on Yubikey forums as a workaround for exclusive card access - and it worked for a while. If I 'primed' the card and got GnuPG to recognise it, it would work until the next machine reboot; it would still work even after sleep. Unfortunately, the probability of that working changed with each major Windows update :-) Is there a way in Windows to find which process is locking the card? I tried using Sysinternals Process Explorer to examine handles opened by scdaemon.exe while it does have access to Yubikey, but I couldn't find anything that would stand out... Thank you, -- Marko Božiković _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
