Gpg.exe hanging

Gpg4win help-en
1

I have a problem similar to (but perhaps a little different from) this: Gpg.exe hangs sometimes

Installed Gpg4win 4.2.0 on Windows 2022 Server. We are using it to decrypt a file that a service provider generates daily. So we have a scheduled task that runs a PowerShell script that downloads this file and invokes gpg.exe to decrypt it. What we’re finding is that occasionally gpg.exe hangs. And unlike the problem I linked to above, it seems to ALWAYS hang after a reboot.

I suspect this has something to do with the fact that the file is not integrity protected. We cannot get our service provider to do this, unfortunately.

The script invokes gpg.exe with these parameters:
–ignore-mdc-error (to deal with the lack of integrity protection)
–pinentry-mode loopback
–batch
–passphrase <>
–output <>
–decrypt <>

What’s odd is that it appears to successfully decrypt the file, but gpg.exe is stuck–the script waits for the process to exit before proceeding, and it looks like it isn’t exiting. Or something.

To troubleshoot, the script now uses gpgconf.exe to stop both gpg-agent and keyboxd then wait 10 seconds and then launch both gpg-agent and keyboxd. The script waits 10 seconds after launching these to try decrypting with gpg.exe. Despite the pause, we sometimes see in the standard error output “gpg: waiting for lock C:\Users\username\AppData\Roaming\gnupg\gnupg_spawn_keyboxd_sentinel.lock…”

Regardless, what I’m really trying to figure out is why gpg.exe is stuck. Or, why it sometimes returns and sometimes does not. This is not an issue with other users on the system. There are no other users on the system, certainly not using any gpg executable.

On our old server, which was using Gpg4win 2.3.3, this didn’t happen. Also, on the old server, we used a gpg2.exe executable, but that does not appear to be available in Gpg4win 4.2.0. As you can guess, we set this up a long time ago, but I have a vague memory that gpg.exe in version 2.3.3 had some similar issues.

Thanks in advance.

2

It seems to ALWAYS hang after a reboot.

I suspect this has something to do with the fact that the file is not integrity protected.

To me that sounds unlikely. To test this, you could create a file that is integrity protected yourself and see if this also hangs after a reboot.

Overall it is good that it hand reliably after a reboot, so this can be debugged better. :slight_smile: There are potential number of causes, I think @aheinecke may have some suggestions. You did use the process explorer already? And turned up the logging?

Also, on the old server, we used a gpg2.exe executable,

gpg.exe is the new version on the Gpg4win 4 (and 3 I think) versions. Check gpg.exe --version to see more.

Regards

3

In my (limited) experience since last week, this is what I have found:

I’m not convinced that gpg.exe is actually hanging. But it isn’t exiting back to PowerShell either, because the script is still waiting for the executable to return.

I think that part of the problem has to do with the gpg-agent and keyboxd daemons. When I said it always hangs after a reboot, it looks like it will hang or have difficulty if the system reboots while gpg-agent and keyboxd are running. If the system reboots while those are running, it seems like gpgconf --kill and gpgconf --launch do not reliably work. In my script I created a loop that tries to kill the daemons, then waits 10 seconds, then tries to launch the daemons, then waits another 10 seconds, then if it looks like either process isn’t running, it tries again. If the system had rebooted while those daemons were running, or if those processes were killed using task manager (instead of gpgconf.exe), then it would take several attempts (4 was the most I saw) to get things going.

Now my script does the following:

  • Uses gpgconf.exe --kill to stop the gpg-agent and keyboxd daemons, if they’re running. Then it waits 10 seconds.
  • Uses gpgconf.exe --launch to start the gpg-agent and keyboxd daemons, then waits another 10 seconds. If either isn’t running, then it tries again.
  • This is the important step I wasn’t doing before: after decrypting the file, use gpgconf.exe --kill to stop these daemons again.

Since last week, it seems like it’s decrypting the file reliably. We’re talking about only 3 or 4 times so far, but one of those was after a reboot.

In summary: using gpg.exe in a script, I’m seeing better results by starting gpg-agent and keyboxd at the beginning and stopping them at the end.

1 Like
4

Thanks for writing down your experiences! That is important feedback so us and also may help others.

There is probably a defect or an inefficiency lurking somehow, and it looks like it is not that easy to trigger or reproduce. Maybe the next person seeing something will help us to get a handle on it.
(The alternative to get this resolved faster would be to analyse your usage and system in great individual detail, which is something that GnuPG.com maybe able to do as part of their paid professional services because it is quite time consuming and thus costly.)

5

I am having a very similar issue. I’m also using gpg4win in a PowerShell script, called by a scheduled task.

What I have discovered is that if keyboxd.exe is not running already, the script will hang (even though it successfully encrypts my file). (The Powershell and console processes will never terminate.) In other words, if the script needs to start up keyboxd.exe itself, it hangs. What I now do to fix this is to terminate the PS process in task manager (which also terminates the console process), but I leave the keyboxd.exe running. The script will then function without issue (until, say, the next server reboot).

I don’t see any issues in the gpg log (on “guru” setting).

I may experiment with starting keyboxd.exe manually in my script, if it’s not already running.

6

I found a fix for my issue: If I remove the “Wait” argument from my “start-process” PowerShell command for gpg, then it seems to work. I looked at the event logs and noticed that keyboxd.exe was starting after gpg, which didn’t seem to make sense since the former is needed by the latter. So I thought maybe that was causing an issue with an infinite wait.

My testing confirms that removing “wait” stops the hanging I was seeing after the keyboxd.exe daemon was terminated.

7

Hi Benny,

I have a longstanding delay/hang issue with gpg4win and emacs on win 10. I recently made one fix, making sure that I was using the right GPG executable. However, there is still a delay of up to one minute when a decryption takes place. I noticed that msmpgeng was active during decryption. I had already excluded several files and directories from virus scanning, which made some improvements. I was able to make additional improvements using this new tool from MS: Performance analyzer for Microsoft Defender Antivirus | Microsoft Learn

It revealed that not only the roaming/gnupg directory is used during this process but also the local/gnupg directory. I excluded that directory as well, and have seen a modest speedup. I also excluded the emacs directory and any other files that I believe are involved. It’s not suggested to exclude prefetch versions of executables, so I haven’t done that. Overall it is still slow but better than before.

Ian