I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

Jochen could you please test this on one of our test VM's again and resolve this then?

I am closing this bug report, as I can't get feedback to fix something.

gniibe: Can you check the status?

Please try this patch:

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

I tested with the GnuPG version 2.0.30 (GPG4WIn) as well as the current 2.1.16
Windows binaries. SCdaemon was running but was unable to get exclusive card access.
Why?
The Cisco Network Manager as well as Cisco Anyconnect VPN did both gain shared
card access (they were not told to do so!). I needed both programs to get access
to the university network.

Uninstalling both Programs and restarting did resolve the issue. To find the
two offenders I used Process Explorer (Processes for all users) and used the
Find Handle or DLL functon with the search term "SCARD". All crosschecked all
Processes (except for scdaemon which sould access the card) and Services
(svchost) to be only scdaemon aswell as the services to be Windows internal.
To determine the inital issue I used
https://sourceforge.net/projects/pcsctracker/ which told me the status of my
Yubikey (as Present,InUse -> Shared Access).

As a suggestion I like to see the experimental option to change the accessmode
from exclusive to shared on the commandline (If for example the other
application cannot be uninstalled).

Which version of GnuPG are you using? Do you have scdaemon?

I've just announced a new 3.0 beta that contains the updated GpgOL

http://lists.wald.intevation.org/pipermail/gpg4win-devel/2016-November/001659.html

Please let me know if it still crashes for you with that version.

Thanks a lot. I will test as soon as you release the test build.

I've tried this again with the current development version after a very large
refactoring how we handle mails. The bug appears to be gone. I've tested 10
times to send a file with closed / open outlook and with and without encryption
active.

If I install gpg4win-2.3.3 on the same system / setup the crash is reliably
reproducible.

It's still likely that we made a reference counting error internally in code
that was changed / fixed now. And Outlook released the Mail object too early and
crashed.

Kaspersky probably had some similar error in their code.

I'll upload a new Gpg4win beta with the new gpgol next. I'll ping in this issue
once thats done so you could ideally confirm that its fixed now.

Fixed with commit df08a0c. Thanks.

That's awesome aheinecke! Honestly wasn't sure if this issue would ever get much
attention. Thanks for the effort in making Gpg4win a more secure product!

GpgOL is built with DEP and and ASLR now. Need to enable this for GpgEX and some
other parts of Gpg4win, too. So not yet fully resolved but I keep it in mind.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

Interesting...

The Kaspersky issue is about Outlook 2007... Is that supposed bug really already
THAT old?!

This could be a nasty one. The crash occurs after the data structure of the mail
was unloaded in outlook and GpgOL already completely detached it's event
handlers from the object and frees up the memory. GpgOL is not executing any
code when the crash occurs. That outlook blames GpgOL is likely because it jumps
into an invalid memory region that was allocated for GpgOL but is no longer
valid. This shouldn't happen though as we have already successfully unregistered
all our callbacks.

So I currently think that somehow when using send from explorer outlook through
some side effect / bug does a callback into GpgOL's event handling code which
was already destroyed. I'll try to confirm that theory on monday by keeping the
event handlers around after the unload event occurred.

Also does not appear that we are the first ones with that problem:
https://forum.kaspersky.com/index.php?showtopic=225375

:-/

Thanks! :-)

Thanks for the report. I am able to reproduce the problem.

Looking into it.