The install location does not have anything to do with that. I just always have my development installations directly under C: so that I can modify them without admin rights.

ok,
well I run "it" on Power Shell ( Debuggable Package Manager ) and I got ..

Do you mean that GnuPG installed to c:/gnupg/bin/ crashed if that mentioned --homedir is given but it does work if it is installed at the standard place? Please run "gpgconf --version" in both ways.

my <output> was the following...

I'd really like to understand what is going on. Thus keeping the report open.

There is now also Gpg4win-3.0.2 with that gnupg version available.

I've been running gnupg-w32-2.2.3_20171207.exe for about as long as it's been available and no hanging whatsoever. Thanks a lot!

All commited. I created a new installer gnupg-w32-2.2.3_20171207.exe which comes with the new libassuan 2.5.1 and the two required patches for gnupg.

I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.

Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth

Looks good. With the libassuan-hang-test.diff and D455 D456 applied on current master branches it no longer hangs. It hung with only the libassuan-hang-test.diff.

The patch above libassuan-hang-test.diff requires D455 and D456 applied.
I guess that without the patch for testing, current gpg-agent would just work fine, possibly. (no crash)

For better reproducibility of hang, this is more better:

I'm doing the test. I'm currently waiting on a hang with the test change applied.

If you can get the developers to make a try-build that is built securely then I'd guess most of us would be happy to try it. Not all of us have a build system for gpg.

To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:

Alright, I need to weight in with something that may possibly be influencing the failure of the December-01-2017 build to operate correctly over here; since this issue is related to sockets, and I have set up a rather unusual security apparatus on my system ("unusual" as far as computers regularly running GPG are concerned, and that only to my personal experience, meaning no reliable statistics or anything), I think it's worth mentioning that my firewall (Sygate Personal Firewall Pro) is configured to be very restrictive and that virtually anything that utilizes tcp or udp is being routed through socks5 via ProxyCap, and that neither application is currently allowing GPG to have access to any address but localhost (there's a reason for this and has got nothing to do with GPG itself, but that's part of a different discussion).

:-(

Ok here's an update.

Superb! Testing gnupg-2.2.3_171201.exe as I type, and it's already working past the time it would normally cease to respond :)

A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.

The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".

Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS

Thanks everyone. I think that the problem is identified and fixed in libassuan.

Update: It was my mistake (typical beginners failure): I had to create gpg-agent.conf instead of usig gpg.conf.
Adding disable-check-own-socket resulted in the right behavior, till now:
After some time-out, GpgOL asks for password again and decrypts the content as expected.

Suppose a client which connects stopped task of server on Windows. In this situation, if the client blocks on closesocket, that is, some user space work is needed for server side for closing socket of client side, this bug can be explained.

If disable-check-own-socket can stop hanging, D454: assuan_close with nPth could be related.

I have created the file "gpg-agent.conf" in the path "C:\Users\<my user>\AppData\Roaming\gnupg\" with the following content:

It's working for me now with that config file as well so far. I'll keep watching too.

I added "disable-check-own-socket" to gpg-agent.conf .
Since 8 hours no "hanging".
I will watch it furthermore...

Could confirm a similar behavior with Windows 7 and Outlook 2010 using GPG4Win 3.0.1.
Time frame for loosing the decryption ability is about one hour or more.
Setting disable-check-own-socket in gpg.conf (didn't find gpg-agent.conf) resulted in "no data" error on all
encrypted e-mails.

In T3378#106503, @raysatiro wrote:

I assume it goes in %APPDATA%\gnupg\gpg-agent.conf.

In T3378#106440, @werner wrote:

Can someone please add

disable-check-own-socket

to gpg-agent.conf to test whether this is the cause for the problem. ( note that I asked for this also in T3401)

Sorry for the delay, been a busy busy couple of weeks..

Setting this to resolved until we get reports to the contrary.

Can someone please add

I introduce GnuPG to my friend, yesterday. I saw this problem. It's on Windows 7, gpg4win 3.0.1 and enigmail.
Looking through this report, Windows 7 is common factor.

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

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

Multiple bugs fixed here:

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

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

Indeed this was a todo that was overlooked.

This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910

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

Indeed bug in Kleo, it was always 0 in kleo. (likely created during Qt5 port) fixed with: https://commits.kde.org/kleopatra/0d53416cfbe6d8fa087887c428cdfffb13514a7d

Duplicated problem. Solution for the installer is described in: T3434

Both my coworker and I have the same issue. We just started using gpg for git commit signing. Works the first time. Then sometime later, no window pops up and will hang git indefinitely because it's waiting on the agent. Kill the agent and gpg process let git error out. try again, gpg-agent window prompting for password shows up and works.

The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code

Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.

So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.

The default for the timeout are 100 seconds. I will chnage that to 15 seconds which is the same what we use for keyservers.

Also failed to replicate on Windows-7 using a dedicated laptop.

I tested for several days with logging enabled but was not able to replicate it again. Then I tried again w/o logging and couldn't replicate it either.

Hi,
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
Regards

Hi,
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.

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

Can you please try again with the standard shell (and not the power shell)?

gniibe: Can you check the status?

I can replicate this now. Unfortunately without logging enabled.

Here is a part of the log inline:

Additional report in https://wald.intevation.org/forum/message.php?msg_id=5308

I added a Workaround in the Wiki: https://wiki.gnupg.org/Gpg4win/releases/3.0/notes

... gpg-agent hangs. After cancelling the process it works again ...

Sorry, I haven't waited long enough.
It's happened again. After leaving Thunderbird open for a while, when consulting another encrypted email, the window asking for the password does not appear and does nothing.
I need Gpg4Win, I'm going back to Gpg4Win 2.3.4

I think it might be a cleanup problem.
If you uninstall Gpg4Win 2.3.4, restart the computer, and then install Gpgp4Win 3.0.0, everything works correctly.

gpg-agent.conf actual content:

Does anyone of you have a gpg-agent.conf and if so, what options are set?

It works correctly when installed and executed.
After a period of inactivity and with Thunderbird still open, it stops working.
With Gpg4Win 2.3.4 it works correctly.

GnuPG is definitely not affected. I do my release test on Vista Ultimate Pro (or whatever it was called)

Someone described this issue with Windows Vista as well.

CancelIoEx is supported by Vista.

Just to inform that it is not a single problem.
I recognized exactly the same behaviour.
After terminating the gpg-agent task everything works as aspected (up to the next non-activity phase).
64-bit Windows 7 Enterprise, Outlook 2010, GPG4Win Version 3.0.0-gpg4win-3.0.0.

Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.

dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

In fact, on Windows you would need to have a system service. We did this in the past for the dirmngr but remove that feature due to possible security problems and problems during installation.

That is correct, gpg-agent does not daemonize on Windows if --daemon is given, it is simply not implemented.