11.0.1267: one IMAP transport thread busy-loops at 100% CPU for days after a fetch times out

Mail
1

Build: eM Client 11.0.1267.0 (Microsoft Store / MSIX), .NET 10 (CoreCLR 10.0.1326), Windows 11 26100, 32 logical cores.

Symptom: after an IMAP fetch on one account stalls and the client gives up, MailClient.exe keeps exactly one CPU core at 100% (≈3.1% in Task Manager on this machine) and never recovers. In our case it ran 52 hours / 187,717 CPU-seconds with no visible error, and the account silently stopped syncing.

Timeline (from eM Client’s own per-account IMAP log):

  • 20:44:57 UID FETCH ... (BODY.PEEK[]) for a 168,919-byte message starts
  • 20:44:59 server starts sending BODY[] {168919}
  • 20:46:04 --- CopyToAsyncWithTimer() timeout — the last line ever written for that account
  • from ~15 min later, one managed thread is pinned at 100% CPU, continuously, until the process is restarted

Forensics:

  • Managed stack (dotnet-stack, 5/5 identical samples):
    MailClient.Imap.Base.TransportPipe+<LoggingHandler>d__39.MoveNext() ← System.IO.Pipelines.Pipe.AdvanceReader / ReadAsync ← System.Threading.Monitor.Enter_Slowpath
  • Runtime counters while spinning: dotnet.process.cpu.time = 1.0 s/s, monitor.lock_contentions = 0, gc.collections = 0, allocation ≈25–50 KB/s, thread-pool queue empty ⇒ a pure busy loop — not workload, not GC, not a lock wait.
  • The dead socket is never closed: netstat keeps it in CLOSE_WAIT the whole time (2.5 days here), while the account shows as online but receives nothing.

Expected: when the CopyToAsyncWithTimer() path gives up, the transport pipe and its logging handler should be disposed and the TCP connection closed. A dead stream must not leave a thread spinning.

Notes:

  • Per-account IMAP logging is enabled here (EnableLog=true), and the spinning frame is the logging handler, so this may only be reachable with logging on — but the missing pipe timeout / dispose guard looks like the real issue.
  • The trigger was a network stall (an idle IMAP connection behind a proxy silently lost its upstream), so the client did nothing wrong at the moment of the stall. What happens afterwards is the bug: no pipe timeout, no dispose, zombie socket, one core burned forever.

Happy to supply more of the trace if that helps.

2

Hi, thank you for this very detailed report, and sorry for the late reply. We have passed it to our developers.

To help them investigate the issue further, could you please provide us with a memory dump of eM Client captured while the application is unresponsive? Please follow these steps:

  1. While eM Client is unresponsive, open Task Manager and locate eM Client under Processes → Apps .
  2. Click the > icon next to it to expand all related processes.
  3. Right-click the largest eM Client process and select Create memory dump file .
  4. ZIP the resulting file and upload it to a cloud storage or file transfer service.
  5. Please email the download link to [email protected] and include a link to this forum post in your email. Make sure the file is accessible either to anyone with the link or shared directly with that email address.

Please also let us know whether the issue still occurs with the latest version of eM Client (you can check your current version under Menu → Help → About ) and whether it always affects the same account or email server.