I think I fixed your problem. We had a similar problem in the past and the fix there was not to invalidate the UI (Update GpgOL's status button) so quickly when the selection changed.

Hi,
thanks for your report. We already have this on our todo with high priority: T3514
I'm resolving this report as a duplicate.

@simypat Please try to move away GnuPG's data directory ( %APPDATA%\gnupg ) and start GPA again. That should fix it as the problem was a corruption of an internal database that lives in the Home directory (and is not removed when uninstalling).

According to our tests and the Message board this is fixed.

Thanks for that assessment.

What happens in the log:

Please do not post warning. They are called warnings for a reason.

Please ignore them.

Fixed for 2.2. Thanks.

I can't reproduce I sent myself serveral messages in which i pasted a PGP Message and they worked. I tried both HTML and Text plain messages.
To be sure I also installed Gpg4win 2.3.0 and sent myself a message with that and that also worked :-/

we uninstalled the old version, restarted, installed the new 3.01, and it still does the error

Thank you for your detailed report and the description for the reproducable setup! We will investigate in that issue!

Nevermind, I did not realize that passwd does not only operate on the selected key but on all keys (subkeys) in sequence.

I've sent an email from Outlook using version 2.3.3, to myself. What I see in Outlook with version 3.0.1 is:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2
hQEMA6jFcgdYY5bVAQgAhWTqExXJVk3aPC5rKYFUeb0NSR+TtChjBzxBrFzQ5qDr
trJiT6o7XoFYDKwdJFXMv81Zcetsu/dOq3dPoCpaQDAtna8xshJDogsx7bOV5bvO
9kLzegZqUk4RzAJLCOTkIISh/Qi6o6kXL4+Iwm17FKfVb0MSAjmrOV50SevrKpD+
PxEYr7BJHRwA9HcYMCb1tvao74AFShZV2olEuwuGvF2nuuqTl6MngKI0Qhteds3F
B6MPOckhHvOCLr3u1z7ld+svggaVFhPyTbXuGxTXAHyieeUr0yf+p4UufdTj3XTn
L/ZeK7l0TKJykbWZmFfZFDClyEDvQx1Vq7ggLuIbh9I/Ab/LkshjC+QGFmfpVaH/
D03ZQv+RStnlI3ZVWvWsAxsaWp/hEsP4RHkmVQXhI4YeRBw1e6TeXzvTvMidjnBC
=oLiX
-----END PGP MESSAGE-----

In the GpgOL ribbon the button shows a question mark and an "unsafe" label.

I tried to remove the passphrase on my authentication subkey but the same issue seems to still be present in version 2.2.2.

We both came from Gpg4win 2.3.2, WE BOTH upgraded to 3.0, as a consequence WE BOTH were unable to decrypt mails once encrypted with Gpg4win 2.3.2 (and actually way older Version of Gpg4win): Please also see https://wald.intevation.org/forum/forum.php?thread_id=1781&forum_id=21&group_id=11 for further description of the issue. Now I AM able to decrypt these mails, my collegue is not (even she also is on 3.0.1).

So to get this straigt:

Unfortunately not, since I am able to decrypt them now (also encrypted with GPG4Win 2.3.2) AFTER the upgrade from 3.0 to 3.0.1 (we both went from 2.3.2 to 3.0 to 3.0.1).

In T3419#106033, @cdeibert wrote:

Hi, VERY odd: My collegue has the exact same installation and environment (actually software deployment-based), she still is suffering to decrypt Mail encrypted with GPG4Win 2.3.2.

Hi, VERY odd: My collegue has the exact same installation and environment (actually software deployment-based), she still is suffering to decrypt Mail encrypted with GPG4Win 2.3.2.

In T3367#106015, @RockyMM wrote:

Treat this as "Cannot Reproduce".

In T3419#105989, @hs wrote:

Just installed Version 3.0.1. From a first glimpse, it seems to work more stable in Outlook context.
But decrypting older plain text messages still fails.

Hi, also installed 3.0.1. For me decrypting older plain text messages now works!

Another log is not needed, as I located the issue. If you can try building GnuPG from Git repo (it's 2.2 branch now), it helps us a lot.

I really want to retest this, but I cannot promise anything. We are using a workaround regarding encrypting email.

Thanks for that clarification Jochen; at least it confirms I'm not going mad. I've got it installed now so will update this if it happens again although, in the meantime, it might be taking a look at the log I attached (if you haven't already) to see if it hints at any behaviour that you know has been fixed.

by "just released" I mean: minutes before i wrote that comment. Since you mentioned gpg4win 3.0.0 in your post, I think you worked with the now old stable release.

Sorry, we can't do anything about it. It is a link to an external site.

Just installed Version 3.0.1. From a first glimpse, it seems to work more stable in Outlook context.
But decrypting older plain text messages still fails.
Using GPA (copying PGP ASCII text into dashboard) decrypts contents without error.
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2
...
-----END PGP MESSAGE-----

Updated this morning and just had a freeze again. Enabled debug mode now. For me the freeze often happens when my pc is locked and I'm not using it for a while, then return to my PC and select another email.

Thank you. Do you still need the log files with the settings suggested by Werner? Would I have to compile the master branch to see if it works now?

Jochen, I've uninstalled the previous version and now installed the most current release. Unfortunately it did not result in a successful run. Here are the details from the event log.

When you say "just was released", do you know what time that was at? My reason for asking is that I checked for an update just before posting this bug report! I'll try it and see how it goes.

This error doesn't seem to appear anymore in Version 3.0.1 and it doesn't exist anymore for me.

@cosimo193 ; gpg4win 3.0.1 just was released. May you check if this error still exists with that new version?

Since there was no action for half a year, I think this task can be closed.

@RockyMM Does this issue still persist with the newer Versions of Gpg4win, like 3.0.1?

@cdeibert, can you may check if this error still exists with the freshly released Version 3.0.1 of Gpg4win?

Unfortunately chocolaty is not managed by us and we don't have the knowledge about this. The Chocolaty Forums/Pages are the better place for this.

Hey @pkoevesdi, Gpg4win Version 3.0.1 was just released. Can you may download and install it and check if this issue still exists?

Hey @cprezalor, the new Gpg4win Version was just released. Can you please download it and check if this error still persists?

Hey, while installing the new Version for checking T3476, you may can check if this issue still persists as well?

@uwestoehr - Gpg4win 3.0.1 just hitted and tehre are several bugfixes including invoking kleopatra from the right-click menu. Can you please install the new version and check if the error still persists?

Version 3.0.1 just hitted. @madjari - may you can check if the various bugfixes in that version fixed your issue as well?

@simypat, version 3.0.1 just hitted. I can't recreate this error anymore. Can you verify this?

With the Release of Gpg4win 3.0.1 this error doesn't appear anymore for me while testing.

With the Release of Gpg4win 3.0.1 the Error doesn't appear anymore while testing with Windows 10 (64bit) with Outlook 2016 and Windows 7 (64bit) with Outlook 2010.

File uploaded is the gpgol debug log file, 7-zipped (it's 165MB without zipping).

Unconditionally retrying without SRV lookup is not a good idea. SRV record are there for a reason. What we could do is an option to skip SRV record lookups.

It's fixed in master.
It is good to backport this to GnuPG 2.2 and GnuPG 1.4.

Thank you for scdamon.log. For the card reader, the interrupt transfer notifies no availability of the card before PC_to_RDR_IccPowerOn.
I fixed this issue in rG0bb7fd0cab2d: scd: Enable card removal check after select_application.. Let's see if it works well for the card reader.

old SRV bug which probably induced code changes for a regression. Its not sure if this is a regression yet or if the router issue is a regression / "feature".

Fixed in 2.2.3 and master. Closing.

This is the actual error message from your log file:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: idVendor: 04E6  idProduct: 5119  bcdDevice: 0525
[...]
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID submit transfer (83): 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed

rO13950a985228 Works around this problem by launching Kleopatra in the background when Outlook is started.
This should both speed up the first operation and work around this issue. In my opinion it's better to waste some resources in the background if Kleo is not needed then to create a bad user experience if encryption does not work and results in a hang of outlook.

Not yet located or identified the bug, but some information.

I could not reproduce it again on Friday. Did some code staring to find the issue but failed. Everything looks Ok.

For some reason, scdaemon.log is not yet available here. Please put it again.

You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.

Ok, edited ~/.gnupg/scdaemon.conf to contain

data.gpg is fine and data2.gpg shows this wired behaviour. The difference is at the end of file last two bytes : 0040 vs. 0a40.
Initally i took data.gpg to create the base64 encoded version for the message.

I tried to reproduce this simply by creating an encrypted file with gpgme/test/run-encrypt and then running kleopatra on it "kleopatra /tmp/foo.gpg" kleopatra prints in debug output the decrypt / verify result from GpgMEpp. No error for me.

Forgot to mention this bug in the commit addressing this. ( 278893850ed926d4646929ee97576a8d09fd4998 )

You may have other changes on your system as well.