No, I used the standard Windows command line

Tried this on Windows 8.1 (x64) with GnuPG 2.2.1 (libgcrypt 1.8.1) and was not able to reproduce it.

Ok, thanks for the explanation.

We had the same effect here and it was caused by a V3 public key in the
keyring.
This key does not show up while listing the public keys with GnuPG 2.1.12. We
could only identify and remove it by accessing the keyring with a GnuPG 1.4.x
installation.
It should be considered to either

• display the key also during the list-keys command (to help the user to track

down the problem)
or

• ignore it silently while building the trust db.

Hi Neal, I am not able to reproduce the issue with GnuPG 2.1.10 anymore.

In gpg4win there is a kwatchgnupg.exe but it throws an error stating that it is
not "installed" within my $PATH variable. The weird thing is, that I started it
from a command prompt somewhere in my filesystem, so its path is set in my $PATH
variable. Strange ...

In last consequence I even tried it with Wireshark and did not get any results
observing localhost and running the command again.

Isn't the output of the log (posted before) enough information or is there any
other way to collect the information you need?

Sorry, but this is not working for me. I do not find watchgnupg executable and
gnupg.org states that this tool does not exist for windows. Maybe I am not clever
enough to find it.
Anyhow I extended the gpg.conf according to your suggestion. (gpg-agent.conf was
already configured like that) I don't know why there is no additional log file
gpg.conf created. I attached my two config files to this issue.

I deleted the "gpg-v21-migrated" file and rerun "gpg -K --verbose". Attached to
this issue you will find my gpg-agent.log . This time it looks like it has more
output in it than the last time.

Would you mind to explain how to enable logging in 2.1?
I tried with --log-file [filename] and --logger-file [filename] but it only
created an empty (0 Bytes) file.
I tried to pipe the output to a file with "gpg -K [--verbose] >
c:\temp\gpg21.log" but this didn't work either. Is the K command supposed to be
"unpipeable"? (The output of "gpg --version" can be piped.)

Missed to explain that this does not happen when using gnupg 2.0.* and this occured
on Windows. I did not try this on *nix.