This is probably related to T4581 and T5760, but I didn't want to hijack those. I also tried the workaround from T5758 -- not setting a reader-port, but to no avail. The only thing that works for me is to kill Kleopatra, which in turn seems to kill the process tree and then upon a second run I often get the certificates loaded quickly. However, sometimes it takes a few tries until it works.
Is there a way to help out with this? I am a developer, I can attach a debugger (in fact I tried), but of course I have no matching debug symbols. Another issue was that the single thread in gpg-connect-agent.exe, the process that seems to hang, is stuck in some kernel call to a synchronization object. You can see it with Process Explorer, but with WinDbg you'd have to establish a kernel debugger connection to get behind what's going on.
I checked and it does not look like it is the loader lock, although I cannot rule it out a 100% at this point. The thread stack looks like this:
ntoskrnl.exe!KeSynchronizeExecution+0x6c56 ntoskrnl.exe!KeWaitForSingleObject+0x1460 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForSingleObject+0x233 ntoskrnl.exe!RtlFindClearBitsAndSetEx+0xc7d ntoskrnl.exe!KiCheckForKernelApcDelivery+0x401 ntoskrnl.exe!KeWaitForSingleObject+0x1787 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForSingleObject+0x233 ntoskrnl.exe!ObWaitForSingleObject+0x91 ntoskrnl.exe!NtWaitForSingleObject+0x6a ntoskrnl.exe!_setjmpex+0x82b5 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x3a5 wow64cpu.dll!BTCpuSimulate+0x9 wow64.dll!Wow64KiUserCallbackDispatcher+0x4b9 wow64.dll!Wow64LdrpInitialize+0x12d ntdll.dll!LdrInitShimEngineDynamic+0x31f1 ntdll.dll!LdrInitializeThunk+0x1db ntdll.dll!LdrInitializeThunk+0x63 ntdll.dll!LdrInitializeThunk+0xe 0x0000000000000000
The command executed shows as "C:\Program Files (x86)\GnuPG\bin\gpg-connect-agent.exe" NOP.
Sometimes, however, there is a gpg-agent.exe as child process of gpg-connect-agent.exe and sometimes subsequently scdaemon.exe as a child process of that.
When this occurs, there are two threads inside scdaemon.exe and there are no observable context switches within one thread in "Wait:Executive" (right inside libnpth-0.dll!npth_setname_np+0x59) state and the other in Wait:UserRequest state. The latter appears to have some activity for it occasionally spends CPU cycles according to the kernel (or Process Explorer). Unfortunately I cannot tell which synchronization object could be the culprit.
I have no smartcards attached on that machine. Or lets put it this way: none I am aware of. If you have a suggestion how to list whatever GPG might consider to be a smartcard, please let me know.
It's an up-to-date Windows 10 (10.0.19045 Build 19045) inside VMware, which in turn runs on Ubuntu 20.04. However, I also have this with a bare-metal installation of Windows, e.g. on my work machine. There I do have a software protection dongle from Feitian as well as a FIDO2 key from Feitian attached. AFAIK these both work via HID (meaning without extra driver involved), though.
While it hangs, I can run gpg -K, gpgsm -K (also with -k, respectively). The first one returns the key lists immediately and as expected, the latter returns immediately without output. However, Kleopatra can hang for hours on end (in the first screenshot I remark on this).
$ gpg --version gpg (GnuPG) 2.4.3 libgcrypt 1.10.2 Copyright (C) 2023 g10 Code GmbH License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: C:\Users\Oliver\AppData\Roaming\gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2
PS: Another thing I have noticed is that the setting for the smart card reader _appears_ to revert to "Default Reader" after setting it to the other one and leaving the field empty, hitting Apply. I have not yet found a reason for this behavior, could as well be a case of PEBKAC on my part.
PPS: I'll also be happy to provide a Process Monitor capture, if you think it could help. However, please point me to your public key(s), so I can encrypt it before uploading.
