GpgOL 2.7.2 hangs 17+ minutes in do_in_ui_thread type=1103 after Send event (network-independent)

Gpg4win help-en
1

Summary

When clicking Send on an encrypted message, Outlook hangs for 15-20 minutes before
the pinentry dialog appears and the message is finally sent. The freeze occurs
reproducibly on multiple client machines in our environment, regardless of antivirus
or network state. Disabling the network does NOT resolve the freeze.

GpgOL debug logs pinpoint the hang to do_in_ui_thread sending a type 1103 message
to the UI thread immediately after the Outlook Send event handler completes. A
secondary hang occurs when resolver.exe is invoked.

Environment

  • Gpg4win 5.0.2
  • GpgOL 2.7.2
  • GPGME 2.0.1
  • Outlook 16.0.0.17932 (Outlook 2024, 64-bit)
  • Windows 10, 64-bit
  • IMAP account (not Exchange, not M365)
  • No smart cards (SCardSvr is not running)
  • gpg.conf has auto-key-locate wkd,local
  • HKCU\Software\GNU\GpgOL\autoresolve = “0”
  • HKCU\Software\GNU\GpgOL\autosecure = “0”

Steps to reproduce

  1. Compose a new email to a recipient whose public key is already in the local keyring
  2. Click the GpgOL Encrypt button (Sign+Encrypt)
  3. Click Send

Result: Outlook UI freezes for 15-20 minutes. Eventually pinentry appears,
user enters passphrase, and the message is sent successfully.

Key timing evidence from the debug log

Each Send produces a multi-minute gap at exactly the same code path. Three
consecutive Send actions in one debug session produced:

Gap 1: 17 min 34 sec
Before: 01:41:58/1796/windowmessages.cpp:do_in_ui_thread: Sending message of type 1103
After: 01:59:32/5292/common.cpp:get_tmp_outfile: Extension found .dat

Gap 2: 1 min 26 sec
Before: 01:59:32/5292/cryptcontroller.cpp:resolve_keys: resolving keys with ‘resolver.exe’
After: 02:00:58/5292/common.cpp:bring_to_front: done

Gap 3: 4 min 42 sec (second Send action, same session)
Before: 02:11:38/15568/windowmessages.cpp:do_in_ui_thread: Sending message of type 1103
After: 02:16:20/10820/common.cpp:get_tmp_outfile: Extension found .dat

Gap 4: 4 min 9 sec (second resolver.exe invocation)
Before: 02:16:20/10820/cryptcontroller.cpp:resolve_keys: resolving keys with ‘resolver.exe’
After: 02:20:29/10820/common.cpp:bring_to_front: done

Notable: each Send triggers three windowmessages of type 1103 sent from three
different thread IDs to the UI thread (5292) just before the freeze:

01:41:58/8172/windowmessages.cpp:do_in_ui_thread: Sending message of type 1103
01:41:58/7440/windowmessages.cpp:do_in_ui_thread: Sending message of type 1103
01:41:58/1796/windowmessages.cpp:do_in_ui_thread: Sending message of type 1103
← hang for 17 min 34 sec →
01:59:32/5292/common.cpp:get_tmp_outfile: Extension found .dat

This pattern suggests the UI thread is blocked or unable to dispatch the
synchronous SendMessage call for an extended period.

What we have ruled out

  • Network: Disabling the network adapter and reproducing offline produces the
    same 17+ minute freeze in the same location. Three offline reproductions
    showed identical gap positions in the log.

  • Antivirus: Reproduced on machines with Windows Defender and on machines with
    ESET NOD32. Identical behavior on both.

  • GpgOL version: Reproduced on both Gpg4win 5.0.2 (GpgOL 2.7.2) and
    Gpg4win 4.4.1 (GpgOL 2.6.2).

  • Smart card subsystem: SCardSvr is not running. gpg --card-status returns
    immediately with “Service is not running”. gpg-agent.conf has no scdaemon
    configuration.

  • gpg-agent startup: gpg --list-keys from cmd returns in milliseconds even
    on a fresh boot. The gpg backend itself is fast.

  • Roaming profile / folder redirection: %APPDATA% resolves to a local path,
    not a UNC share.

  • autoresolve / autosecure: Set to “0” prior to all tests above. These fixed
    the freeze when opening compose window, but not when clicking Send.

  • Legacy Symantec PGP Desktop: Never installed on these machines.

  • Encryptomatic / other PGP COM add-ins: Not installed.

What we tried

  • Set autoresolve=“0” and autosecure=“0” → Fixed compose-window hang but
    NOT the Send hang
  • Downgrade to Gpg4win 4.4.1 → No effect
  • Reinstall Gpg4win → No effect
  • Disable network → No effect on Send hang

Attached files

  • Full GpgOL debug log covering three consecutive Send actions (one online,
    two offline)
  • Registry export of HKCU\Software\GNU\GpgOL

Affected users

gpgol.txt (115.3 KB)

This is reproducible across multiple end-user machines in our deployment
(approximately 10 users, all configured identically). Not a single-machine
issue.

2

Hello Chris, thank you for the excellent report!

We had a few similar (if not as thorough) reports and have now a suspect for the cause. If questions arise during our ongoing investigation we’ll come back to you.

3

The suspicion for a cause in the other case didn’t pan out and it seems the cases are not connected.

Which encoding is used on the systems, do you use a multi byte code encoding? Or does this occur with UTF-8?

Would you be willing to make a test run with a gpgol.dll modified to give more log details?

4

Hi,

Thanks for your kindly reply.

Yes, the systems use multi-byte encoding (CP936 / GBK, Simplified Chinese). The system locale is set to Chinese (PRC). chcp returns 936. The “System locale for non-Unicode programs” setting in Control Panel → Region is also “Chinese (Simplified, China)”.

All test machines use the same regional settings.

and

Yes, absolutely happy to run a custom build for debugging. Please send the modified gpgol.dll (or a link/zip), and I’ll deploy it on a test machine and capture a new debug log of the freeze.

Some questions to confirm the procedure on my side:

  • Path to replace: I assume C:\Program Files\Gpg4win\bin\gpgol.dll. Should I keep Gpg4win 5.0.2 installed and just swap this single file?

  • Do I need to re-register the COM component (regsvr32) after replacement?

  • Any specific environment variables or registry keys to set for your added logging output?

I can run the test after received the build ASAP.

5

Hi Chris,
unfortunately Gpg4win does not support multi-byte encoding, only UTF-8. We believe the issue is cause by the encoding.

But we would have a look at the issue anyway and see if it is something easily fixed.

Path to replace: I assume C:\Program Files\Gpg4win\bin\gpgol.dll.

Yes, as your Outlook is the usual 64bit version.

Should I keep Gpg4win 5.0.2 installed and just swap this single file?

yes.

Do I need to re-register the COM component (regsvr32) after replacement?

You only need to restart Outlook.

As to the last question: The info will come from the developer preparing the debug-version. And before you ask: I don’t know when it will be ready.

6

Thanks for the clear explanation — that confirms our suspicion that this is a systemic encoding issue affecting most Windows users in China, since the default system locale here is CP936 (GBK).

Looking forward to the debug build whenever it’s ready. I’ll run it on the test machine and report back with logs as soon as I have it.

In the meantime, do you have any short-term workaround suggestions for users on multi-byte locales? For example, would forcing the Windows “System locale for non-Unicode programs” setting to “English (US)” be expected to work around the issue temporarily?

7

I am not knowledgeable in that area but I’d not expect it, as the issue here is that the system itself is non-Unicode and the program needs Unicode. I’d think using Outlook with en-US setting might be worth a try, though.

What you can always do is deacivate (or deinstall) det GpgOL Add-In and attach already encrypted files. I am not aware of any complaints that file encryption with Kleopatra (or GpgEX) does not work with multi-byte encoding.