[Edit] Installed successfully, but no reaction from MiniDump when the problem occurs. When I make PMail "hang" (grey screen, "Not Responding" in the top bar) nothing happens. When I X out I get Windows errors of a crash, but no MiniDump dialog as promised.

Tried "Snapshot", didn't provide any info in the draft, sent that email.

Thanks, got it and has done its job, but from this posted thread here I already got the impression that it won't help a lot since - as already stated by Brian - PM is just doing its job, so the result is:

ntdll!NtWaitForSingleObject

This means that the main thread is waiting for something to finish in another thread. I can't provide any more details since I don't have access to the sources, and even if so, I would have difficulties reading it since it's not my own code and in a different (programming) language. The only one to provide any further information is David Harris, whom I'll try to ask for a comment.

PS: From the details in your email I understand that LoadWinSock is disabled in Pegasus Mail, maybe you should try again with LoadWinSock set to Always on Tools > Options > Advanced settings. I'm not very positive on this solving the issue, but it's easy enough to figure out.

PPS: You need to restart Pegasus Mail for it to take effect.

Thanks Michael! With any luck David Harris can shed some light on what PM's waiting for and why.

I'll need to check on the WinSock setting effect tomorrow.

Have you tried having a task manager windows opened.
Then do the upload, and switch to the taskmanager windows and see what processes it shows as running the highest?
Is it Pegasus or someother process.

PMail is not processing. It's momentarily comatose for ~40 seconds several times in a 9MB file send.

Guess I wasn't clear on what I was referring too.
Know that you are saying that Pegasus stops running (hung).
But usually that would mean it is waiting for something else to finish.
So if Pegasus is waiting, something else must be running during that time.

Know Pegasus itself doesn't do the transfer of the messages, but some windows process or service.

On my linux system, running Pegasus under wine, but I use stunnel to actually handle the uploading and downloading of the messages. So Pegasus hads over the processing. Assume you are using the regular Pegasus mail process, so it is using something in windows to do it.

As an example. Made a single message with a 21K attachment and sent it.
Have stunnel run at a high log level, and this is what it reports in that session.

Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Service [gmailsmtp] started
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Setting local socket options (FD=3)
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Option TCP_NODELAY set on local socket
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: Service [gmailsmtp] accepted connection from 127.0.0.1:53874
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: s_connect: connecting 74.125.137.109:465
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: s_connect: s_poll_wait 74.125.137.109:465: waiting 10 seconds
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: FD=6 events=0x2001 revents=0x0
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: FD=17 events=0x2005 revents=0x0
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: s_connect: connected 74.125.137.109:465
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: Service [gmailsmtp] connected remote server from 192.168.1.16:42250
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Setting remote socket options (FD=17)
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Option TCP_NODELAY set on remote socket
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Remote descriptor (FD=17) initialized
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: SNI: sending servername: smtp.gmail.com
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: No previous session to resume
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: Peer certificate required
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): before SSL initialization
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Initializing application specific data for session authenticated
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS write client hello
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS read server hello
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): TLSv1.3 read encrypted extensions
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Verification started at depth=2: C=US, O=Google Trust Services LLC, CN=GTS Root R1
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: CERT: Pre-verification succeeded
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP: Ignoring the root certificate
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: Certificate accepted at depth=2: C=US, O=Google Trust Services LLC, CN=GTS Root R1
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Verification started at depth=1: C=US, O=Google Trust Services, CN=WR2
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: CERT: Pre-verification succeeded
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: OCSP: No AIA responder URL
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: Certificate accepted at depth=1: C=US, O=Google Trust Services, CN=WR2
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Verification started at depth=0: CN=smtp.gmail.com
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: CERT: Pre-verification succeeded
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: CERT: Host name "smtp.gmail.com" matched with "smtp.gmail.com"
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP: Waiting for OCSP stapling response
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: Certificate accepted at depth=0: CN=smtp.gmail.com
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): TLSv1.3 read server certificate verify
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP stapling: Client callback called
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG3[0]: OCSP: No OCSP stapling response received
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: OCSP: Connecting the AIA responder "http://o.pki.goog/wr2"
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: s_connect: connecting 172.217.12.131:80
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: s_connect: s_poll_wait 172.217.12.131:80: waiting 5 seconds
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: FD=6 events=0x2001 revents=0x0
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: FD=18 events=0x2005 revents=0x0
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: s_connect: connected 172.217.12.131:80
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP: Connected o.pki.goog:80
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP: Response received
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: OCSP: Validate the OCSP response
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: OCSP: Status: good
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: OCSP: This update: 2025.11.13 21:06:45
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: OCSP: Next update: 2025.11.20 20:06:44
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: OCSP: Certificate accepted
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG5[0]: OCSP: Accepted (good)
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS read finished
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS write finished
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: 1 client connect(s) requested
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: 1 client connect(s) succeeded
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: 0 client renegotiation(s) requested
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: 0 session reuse(s)
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: TLS connected: new session negotiated
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption)
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG6[0]: Peer temporary key: X25519, 253 bits
Nov 14 08:09:07 setzcodell stunnel[1543]: LOG7[0]: Compression: null, expansion: null
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSL negotiation finished successfully
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSL negotiation finished successfully
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Initializing application specific data for session authenticated
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Deallocating application specific data for session connect address
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: New session callback
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Peer certificate was cached (5302 bytes)
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Initializing application specific data for session authenticated
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG6[0]: Session id: D44E116C5E42099A6D4745DB546DB0C97D97F71AB66E585E47D6DA4A706D3329
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSL negotiation finished successfully
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSL negotiation finished successfully
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Initializing application specific data for session authenticated
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Deallocating application specific data for session connect address
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: New session callback
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Deallocating application specific data for session connect address
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: Initializing application specific data for session authenticated
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG6[0]: Session id: F6ED35A4710FE351818836C9E8F411AAF6D8A7366FFF8EB99341F873FB2AA583
Nov 14 08:09:08 setzcodell stunnel[1543]: LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG6[0]: Read socket closed (readsocket)
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Sending close_notify alert
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: TLS alert (write): warning: close notify
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG6[0]: SSL_shutdown successfully sent close_notify alert
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG6[0]: TLS socket closed (SSL_read)
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Sent socket write shutdown
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG5[0]: Connection closed: 32652 byte(s) sent to TLS, 691 byte(s) sent to socket
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Deallocating application specific data for session connect address
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Remote descriptor (FD=17) closed
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Local descriptor (FD=3) closed
Nov 14 08:09:10 setzcodell stunnel[1543]: LOG7[0]: Service [gmailsmtp] finished (0 left)

That was just the SSL connection, but your system, there might be some anti-virus/anti-malware program that might also be part of the process in checking that attachment is clean. Could also be your smtp server runs its own scan on attachment before issuing the reply..

If it creates and smtp log, it might show more, but don't know what log level Pegasus has it set for. I use log level 7 via stunnel. Again, have to check on internet log box, and then to upload attempt to get a log, and see what it might show.
Task manager might show that some other windows process is activated and running during that 40 second pause.

In linux, I would run top command to show what other tasks are running, but task manager should be similarly able to do it.

I don't see that a Windows process could be the cause here considering that SMTP sends to one host work fine while they don't to another with both hosts using the same port. I seems to me that whatever this issue is, it is specific to the problem host. I don't know what communications occur between Pegasus Mail and an SMTP server during transmission but the fact that Pegasus Mail shows minimal processing activity while appearing to be hung makes me think that it is waiting for a response, as if waiting for receipt confirmation before transmitting the next block of data. This is just conjecture though.

Michael IDW is trying to get this in front of David Harris so let's hope for a response that is enlightening.

From David's reply:

It looks as though the WinSock stack is stalling during calls to "select()"
(which is the WinSock function used to determine whether or not data is
available to be read, or has finished being written). In order not to stall the
user while TCP/IP is in progress, WinPMail calls select() with a short timeout
(usually a second): if there is no readable data or data remains to be written,
select() is meant to return immediately without blocking the thread, and not to
exceed the timeout (1s) under any circumstances.
In the "bad old days" (Windows 95/XP) I'd occasionally see this kind of
problem, and the only conclusion I was ever able to reach was that it was
either external interference, or the WinSock stack getting into a strange
state.

Then there are a couple of suggestions he got from ChatGPT, some of those already provided by Brian:

Disable "email scanning" features in their AV and retry.
Try sending using a different port (587 instead of 465 or vice versa).
Restart home router; if possible, test on another network (hotspot).
Ask ISP support:
Are you rate-limiting or AV-scanning outbound SMTP?
Are there known MTU issues on my line?
If possible, run ping MTU tests:
ping -f -l 1472 smtp.isp.example

Some more comments about this case you're dealing with:

I had a look at his session log, and can see the delays - it's interesting that they only occur in the application/octet-stream section of the message (a .PDF attachment, which are very troublesome just at the moment). This would lead me to suspect strongly that it's some kind of content filtering happening during the transaction - either an A/V package, or perhaps the ISP's network or server (he may have an Intruder Detection System like an Ironwall that is examining the data).

More thoughts:

Given the sheer number of Pegasus Mail and Mercury users there are out there, I would have expected that if this was a specific problem in my TCP/IP library, then I'd have heard of it more often, but this is the first report of this kind I've seen in probably a decade or so.

HTH

FYI in the interim:

• "always" vs "on demand" WinSock makes no difference.
• Installed clean on a brand new machine running Windows 11. Set up identity, options and SMTP server exactly as on the other machine (cold type, no transferring files or copy-paste). Attached the PMail download file as the attachment (so pdf appears not to be involved, see David above). Exact same response from PMail.

I'll take all that to my host server guy see if he can make heads or tails of it.