I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.

Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I found that there are many such solutions on the Internet. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.

Thanks!
I will study it soon.

I tested the change of last_update after importing a same key with different content, but found that there is still no change.

After several days of observation, after modifying the configuration file options , the problem has indeed been greatly alleviated.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

debug network,dns,ipc
log-file C:\Users\Administrator\dirmgr.log

I wrote this in my dirmngr.conf. But i haven't found this .log file.

Yes, I infer that the problem lies in the network-related modules. Because this waiting time is too long, it is probably not a problem of calculation and disk.

Let me try, this problem sometimes happens, so it may takes some time to come to a conclusion.
But what I know is that after experiencing slow loading, it will not appear again when it is opened again later.

Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!

Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.

The problem has been solved by me, but this and the problem are still very strange.

Let me explain this problem more clearly. GPGME did not correctly receive and parse the output from gpgconf. Looking at the log file, EOF was generated when 4096 bits were read. So in engine info, although the path is correct, the identification of the version number is 1.0.0, and there is only gpgconf in the protocol, but there are no protocols such as gpg, assume, etc., which just means that gpgme does not correctly identify the output of gpgconf in this environment Information to find other protocols.
At the same time, I verified whether the output in gpgconf and the path of the related configuration are correct (whether there is a corresponding tool under the path), these are all right, which is very strange.

This is the log file output after the GPGME DEBUG environment variable is set.

I tried again after cloning the master branch, and I finally figured it out. Sorry for the trouble caused by this irrelevant question just submitted. thanks again.

A popular way is to export the subkey, delete the existing key pair, and then import the subkey back, so that the actual value of the master key will not appear in the key pair to protect the master key(The value of the master key will be backed up and stored in another safe place).
At this time, gpg -K will display the following for this key pair:

thanks!