In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)

I can reproduce that it won't be moved.

This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.

A wait, we have T4203 for the continuing problems. So let's close this.

This was likely one form of T4111

3.1.4 was released.

This had also something to do with the missing keycache that will be released in 3.1.5 so that sometimes S/MIME keys were not cached internally and so would not be used.

There is still at least one report claiming that this still happens for large attachments. I could not reproduce it.

This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.

I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes. Thanks! I'm at over 2500 S/MIME verify operations without a crash now!

Yes! Thank you very much. My test runs and my Outlook has verified 2500 S/MIME Mails without a crash.

I'm currently looking at the CloseHandle in _gpgme_io_close:

Btw I've checked that the errors are the same in T4111 and this:

Certificate though has a nicer connotation to it and definitely feels like it has the connotation of something to be shown off to other people and displayed on walls, which I really like.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

Fixed it myself as I confirmed the leak with Dr. Memory.

I've seen now four crashes in _gpgme_io_spawn. I've added tracing that shows that the CreateProcess itself is crashing. I do not see how this is possible. I'm printing the command line and the program name in debug output and both look fine.
The command line is also mutable.

I'm also seeing hangs. Sometimes with gpgsm running. Sometimes without it running.

It builds for me now. I had a mismatch with a to old gpgrt-config and did not properly set PKG_CONFIG_PATH

libassuan master fails to compile for windows against libgpg-error master http://paste.debian.net/1049534/ I think gpg-error.m4 ignores both sysroot and --with-gpg-error-prefix

I can only tell that the term "Certificate" is exactly what Kleopatra was trying to use consistently in the GUI. For Kleopatra it is also important because it tries to work with both X509 "certificates" and OpenPGP "public keys".

Did you have the chance to try it out with 3.1.4?

I've closed this as a dup because the pinentry-qt is the default one on Windows and T4123 describes your problem.

Is it possible that you have used a different pinentry in the past? Like the GTK one?

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.