Community Discussions and Support
Pmail hangs on sending SMTP

Running Pmail v.4.91.1746 on Windows 10 PC.
The following happens on two separate machines running the same set-up, one a laptop, one a desktop.


When sending SMTP [edited], Pegasus hangs (aqua ring, no functionality, not even X out) for a time period - momentary with small size messages, longer with bigger attachments. The short ones are tolerable, but when sending a 10MB attachment, the total message send time can be several minutes of PMail hung up (progress clocks in short bursts, not slow crawl). If I try to use PMail during the 'pauses', it grays out and starts acting locked up. But either way, eventually coughs out the email.


The interesting bit is it only happens sending via one host SMTP [edited] server (to which I recently switched one account).


I have a different host with which sending pop this does not happen.


I have worked with the problem host (he's a small shop and very hands on) and we are not finding anything in logs that explains what's going. His end just shows a really slow pop transfer with no messages from my end to hold, or of any issue. On my end each package transfer is recorded, just with inexplicable time gaps between them when it hits the large attachment email. Doing this live with the host on the phone watching logs his logs are showing his system is just waiting on me, no error or problem indicator from me, nor on his end indicating it's his system pausing things.


I'm not too technically experienced (but a quick learner), he is experienced, and from what we see it seems like there's a PMail program / code issue with something about transferring to his server (which PMail does not have with the other host).


Any ideas?


Running Pmail v.4.91.1746 on Windows 10 PC. The following happens on two separate machines running the same set-up, one a laptop, one a desktop. When sending SMTP [edited], Pegasus hangs (aqua ring, no functionality, not even X out) for a time period - momentary with small size messages, longer with bigger attachments. The short ones are tolerable, but when sending a 10MB attachment, the total message send time can be several minutes of PMail hung up (progress clocks in short bursts, not slow crawl). If I try to use PMail during the 'pauses', it grays out and starts acting locked up. But either way, eventually coughs out the email. The interesting bit is it only happens sending via one host SMTP [edited] server (to which I recently switched one account). I have a different host with which sending pop this does not happen. I have worked with the problem host (he's a small shop and very hands on) and we are not finding anything in logs that explains what's going. His end just shows a really slow pop transfer with no messages from my end to hold, or of any issue. On my end each package transfer is recorded, just with inexplicable time gaps between them when it hits the large attachment email. Doing this live with the host on the phone watching logs his logs are showing his system is just waiting on me, no error or problem indicator from me, nor on his end indicating it's his system pausing things. I'm not too technically experienced (but a quick learner), he is experienced, and from what we see it seems like there's a PMail program / code issue with something about transferring to his server (which PMail does not have with the other host). Any ideas?
edited Nov 9 '25 at 5:05 pm

The topic "Pmail hangs on sending pop" is confusing. What do you mean by "pop" here and "sending pop" used later in your post. If "pop" means POP3, well that is not involved in sending, SMTP does the sending. The fact that the delay only occurs with one SMTP server indicates that problem is not with Pegasus Mail but with that server, or the connection to it. I'm sure you have confirmed with the provider what port to use as well as whether security should be SSL or STARTTLS so the only other thing that comes to my mind is whether you are using an anti-malware product that is scanning outgoing traffic on the port being used by the problem SMTP host. Is the SMTP host that is working fine using the same port as than the problem one?


The topic "Pmail hangs on sending pop" is confusing. What do you mean by "pop" here and "sending pop" used later in your post. If "pop" means POP3, well that is not involved in sending, SMTP does the sending. The fact that the delay only occurs with one SMTP server indicates that problem is not with Pegasus Mail but with that server, or the connection to it. I'm sure you have confirmed with the provider what port to use as well as whether security should be SSL or STARTTLS so the only other thing that comes to my mind is whether you are using an anti-malware product that is scanning outgoing traffic on the port being used by the problem SMTP host. Is the SMTP host that is working fine using the same port as than the problem one?

When sending pop, Pegasus hangs (aqua ring, no functionality, not even X out) for a time period - momentary with small size messages, longer with bigger attachments.
In addition to what @Brian said, it's important to point out that:

  1. "hang" can be interpreted as simply the time required for Pegasus Mail to convert a large binary attachment into text (e.g., Base64);
  2. If the attachment is already large, the fact that it needs to be converted to text will result in a considerable increase in bytes, something like +33.33%, which will require even more transmission time. In these cases, a longer timeout is advisable. If hanging is true, than the use of IdW's MiniDump/PmDebug is a must;
  3. Email servers reject long messages and especially long attachments, whether numerous and/or large;
  4. Finally, would you be willing to share a session log (please remove authentication data) so that we can assess where the problem lies, whether in Pmail or your email provider?

[quote="pid:58215, uid:38982"]When sending pop, Pegasus hangs (aqua ring, no functionality, not even X out) for a time period - momentary with small size messages, longer with bigger attachments.[/quote]In addition to what @Brian said, it's important to point out that: 1. _"hang"_ can be interpreted as simply the time required for Pegasus Mail to convert a large binary attachment into text (e.g., Base64); 2. If the attachment is already large, the fact that it needs to be converted to text will result in a considerable increase in bytes, something like +33.33%, which will require even more transmission time. In these cases, a longer timeout is advisable. If hanging is true, than the use of IdW's MiniDump/PmDebug is a must; 3. Email servers reject long messages and especially long attachments, whether numerous and/or large; 4. Finally, would you be willing to share a session log (please remove authentication data) so that we can assess where the problem lies, whether in Pmail or your email provider?

-- Euler

Pegasus Mail 4.91.1746 Windows 7 Ultimate
IERenderer: 2.7.3.5 AttachMenu: 1.0.2.0
PMDebug: 2.5.8.37 BearHTML 4.9.9.6

Thanks for the replies!


The topic "Pmail hangs on sending pop" is confusing.
Apologies. Yeah, like I said, I'm not too technically advanced. Of course, the issue is in the SMTP server when sending. (No excuse but: I think of this host as my "pop" host compared to the nightmares I had with MS365.)


the only other thing that comes to my mind is whether you are using an anti-malware product that is scanning outgoing traffic on the port being used by the problem SMTP host
We went through all of that, confirmed all settings, and ended up also thinking malware protection was the issue: uninstalled it (AVG) and still had the same issue.


"hang" can be interpreted as simply the time required for Pegasus Mail to convert a large binary attachment into text
It "appears" to hang. Think of it as talking to someone who speaks in parts of the full sentence, but pauses 30 seconds unexpectedly in the middle and just stares at you unresponsive "appearing to be comatose" then finishes the sentence. The key here is it does not do this with a different host. Just this one. With my other SMTP host the exact same attachment email grinds happily away for five seconds or so and is gone, and all the while it's churning I can still use PMail: no blue wheel 'o death or greyed out PMail when I try to do anything with it like I get with the other host.


Something is going on between PMail and this new host, but we can't seem to find anything in the actual SMTP transfer process going wrong. In an another analogy, it's like (again: looks like it, not claiming it) PMail itself (the software code) is allergic to this host in a way which causes PMail to repeatedly 'stick' after pumping out a bit of message, then wake up and keep going.


I'll post my logs in a bit (soon as I figure out how and have a second cuppa for clarity.)
I'll see if my host is able to get on this thread as well; he'll provide a much better technical perspective from his end.


Thanks for the replies! [quote="pid:58216, uid:28772"]The topic "Pmail hangs on sending pop" is confusing.[/quote]Apologies. Yeah, like I said, I'm not too technically advanced. Of course, the issue is in the SMTP server when sending. (No excuse but: I think of this host as my "pop" host compared to the nightmares I had with MS365.) [quote="pid:58216, uid:28772"]the only other thing that comes to my mind is whether you are using an anti-malware product that is scanning outgoing traffic on the port being used by the problem SMTP host[/quote]We went through all of that, confirmed all settings, and ended up also thinking malware protection was the issue: uninstalled it (AVG) and still had the same issue. [quote="pid:58217, uid:2194"]"hang" can be interpreted as simply the time required for Pegasus Mail to convert a large binary attachment into text[/quote]It "appears" to hang. Think of it as talking to someone who speaks in parts of the full sentence, but pauses 30 seconds unexpectedly in the middle and just stares at you unresponsive "appearing to be comatose" then finishes the sentence. The key here is it *does not* do this with a different host. Just this one. With my other SMTP host the exact same attachment email grinds happily away for five seconds or so and is gone, and all the while it's churning I can still use PMail: no blue wheel 'o death or greyed out PMail when I try to do anything with it like I get with the other host. *Something* is going on between PMail and this new host, but we can't seem to find anything in the actual SMTP transfer process going wrong. In an another analogy, it's like (again: looks like it, not claiming it) PMail itself (the software code) is allergic to this host in a way which causes PMail to repeatedly 'stick' after pumping out a bit of message, then wake up and keep going. I'll post my logs in a bit (soon as I figure out how and have a second cuppa for clarity.) I'll see if my host is able to get on this thread as well; he'll provide a much better technical perspective from his end.
edited Nov 9 '25 at 5:07 pm

Abbreviated log file during SMTP send when using the "problem" host.
I took out what I think is the secure access info, if I should take out more please let me know so I can take it down.


I snipped out the boring bits where packets happily chug along in microsecond bursts. I left the bits where there are inexplicable ~40 second pauses between two packets. This is an excerpt of one. 12:43:45.580 right to 12:44:25.390. 40 seconds of pause with no logged issue on PMail's side (nor any request/notification from PMail or command to PMail on host's side)


12:43:45.563: << fJAOSPUA8Rpp4lCaf1d5Lprj2g+6NP71T3XPr9Y6OIgDxI7qWeXhERW+zHGFmR7Os3I9Gz02<cr><lf>
12:43:45.580: << N3F0k+ERqSeyy7s+4FlMg1unT95xbH3aqW91Vb7HyHnmRz4yqlTRl5PqUMlrW+7ce/Yx5eCz<cr><lf>
12:44:25.390: << pkzz2O+jZieHHX2urTIfW6w+4tJd8dNI8lR6o4Uk3sIfGmwydP5P7vw4V6k/pWjkgE+J18Tx<cr><lf>
12:44:25.394: << KLeNC71CwwY1EfcVqCN2A0zKqLzFb/V3hoftmRpBHfVXsMVX/pHuc0jR0jgxGsfkUr32Xgsa<cr><lf>


[Edit]TCP-250923-1243-6 Imageway - Trimmed.txt


[Edit]FWIW I scanned through the log using the other host with no apparent issues thinking maybe there were also pauses, just too short to notice. No luck. Longest pause I could find was < 0.1


Abbreviated log file during SMTP send when using the &quot;problem&quot; host. I took out what I think is the secure access info, if I should take out more please let me know so I can take it down. I snipped out the boring bits where packets happily chug along in microsecond bursts. I left the bits where there are inexplicable ~40 second pauses between two packets. This is an excerpt of one. 12:43:45.580 right to 12:44:25.390. 40 seconds of pause with no logged issue on PMail&#039;s side (nor any request/notification from PMail or command to PMail on host&#039;s side) 12:43:45.563: &lt;&lt; fJAOSPUA8Rpp4lCaf1d5Lprj2g+6NP71T3XPr9Y6OIgDxI7qWeXhERW+zHGFmR7Os3I9Gz02&lt;cr&gt;&lt;lf&gt; 12:43:45.580: &lt;&lt; N3F0k+ERqSeyy7s+4FlMg1unT95xbH3aqW91Vb7HyHnmRz4yqlTRl5PqUMlrW+7ce/Yx5eCz&lt;cr&gt;&lt;lf&gt; 12:44:25.390: &lt;&lt; pkzz2O+jZieHHX2urTIfW6w+4tJd8dNI8lR6o4Uk3sIfGmwydP5P7vw4V6k/pWjkgE+J18Tx&lt;cr&gt;&lt;lf&gt; 12:44:25.394: &lt;&lt; KLeNC71CwwY1EfcVqCN2A0zKqLzFb/V3hoftmRpBHfVXsMVX/pHuc0jR0jgxGsfkUr32Xgsa&lt;cr&gt;&lt;lf&gt; [Edit][TCP-250923-1243-6 Imageway - Trimmed.txt](serve/attachment&amp;path=6910da84b0888) [Edit]FWIW I scanned through the log using the other host with no apparent issues thinking maybe there were also pauses, just too short to notice. No luck. Longest pause I could find was &lt; 0.1
edited Nov 9 '25 at 6:29 pm

I uploaded a file, but don't see it in the thread. Is it available?


I uploaded a file, but don&#039;t see it in the thread. Is it available?

Look in the SMTP host configurations to see if the problem one is using port 465 but the good one is not. I suggest this because...
... research done just now indicates that port 465 is the SMTP port being scanned by default by AVG.
... AVG was a problem for me years ago, and was very difficult to get completely uninstalled. IIRC, its email shield would not uninstall if it was enabled when AVG was uninstalled. I think I had to use an AVG removal tool. A quick search found two:



Look in the SMTP host configurations to see if the problem one is using port 465 but the good one is not. I suggest this because... ... research done just now indicates that port 465 is the SMTP port being scanned by default by AVG. ... AVG was a problem for me years ago, and was very difficult to get completely uninstalled. IIRC, its email shield would not uninstall if it was enabled when AVG was uninstalled. I think I had to use an AVG removal tool. A quick search found two: - AVG Clear authored by AVG Technologies according to this site: https://www.bleepingcomputer.com/download/avg-clear/. - AVG Uninstall Tool is linked to on this AVG support site (click the &quot;Articles&quot; link on the left of the page for details): https://support.avg.com/kA60N0000004aGy?name=uninstall-avg-software-clear-remover&amp;language=en_US

I uploaded a file, but don't see it in the thread. Is it available?


It isn't. Some file types are not allowed so perhaps that is the problem. Pasting it into a reply is an option. Remove the content between the "AUTH LOGIN" entry and the "Authentication Successful". It contains your credentials, likely encoded but in easily decodable form.


[quote=&quot;pid:58220, uid:38982&quot;]I uploaded a file, but don&#039;t see it in the thread. Is it available?[/quote] It isn&#039;t. Some file types are not allowed so perhaps that is the problem. Pasting it into a reply is an option. Remove the content between the &quot;AUTH LOGIN&quot; entry and the &quot;Authentication Successful&quot;. It contains your credentials, likely encoded but in easily decodable form.

It isn't. Some file types are not allowed so perhaps that is the problem.
Yeah, .smtp appears to be on the 'no fly' list. Uploaded as .txt. Have fun!


[quote=&quot;pid:58222, uid:28772&quot;]It isn&#039;t. Some file types are not allowed so perhaps that is the problem.[/quote]Yeah, .smtp appears to be on the &#039;no fly&#039; list. Uploaded as .txt. Have fun!

Look in the SMTP host configurations to see if the problem one is using port 465 but the good one is not.
Both are 465 :-( I'll try an AVG uninstall again with those tools. That'd be a nice easy fix if it's the issue.


Thanks for the efforts, btw smile


[quote=&quot;pid:58221, uid:28772&quot;]Look in the SMTP host configurations to see if the problem one is using port 465 but the good one is not.[/quote]Both are 465 :-( I&#039;ll try an AVG uninstall again with those tools. That&#039;d be a nice easy fix if it&#039;s the issue. Thanks for the efforts, btw :)
edited Nov 9 '25 at 6:31 pm

Both are 465 :-( I'll try an AVG uninstall again with those tools. That'd be a nice easy fix if it's the issue.


It probably isn't the issue since both are using port 465 but only one is being affected with the slow sending issue.

Yeah, .smtp appears to be on the 'no fly' list. Uploaded as .txt. Have fun!


That didn't work either. Might have to copy/paste the contents into a reply, removing the authentication credentials in the process.


[quote=&quot;pid:58224, uid:38982&quot;]Both are 465 :-( I&#039;ll try an AVG uninstall again with those tools. That&#039;d be a nice easy fix if it&#039;s the issue.[/quote] It probably isn&#039;t the issue since both are using port 465 but only one is being affected with the slow sending issue. [quote=&quot;pid:58223, uid:38982&quot;]Yeah, .smtp appears to be on the &#039;no fly&#039; list. Uploaded as .txt. Have fun![/quote] That didn&#039;t work either. Might have to copy/paste the contents into a reply, removing the authentication credentials in the process.

That didn't work either. Might have to copy/paste the contents into a reply, removing the authentication credentials in the process.
The link in my edited post doesn't work for you? Works for me.
AVG was a problem for me years ago, and was very difficult to get completely uninstalled. IIRC, its email shield would not uninstall if it was enabled when AVG was uninstalled. I think I had to use an AVG removal tool. A quick search found two:
Used AVG Clear tool again (had used it the previous time) and no change in action with PMail.


I'm actually getting a new machine delivered today for unrelated reasons. Going to get that one up and running and first application install will be PMail for a test.


[quote=&quot;pid:58226, uid:28772&quot;]That didn&#039;t work either. Might have to copy/paste the contents into a reply, removing the authentication credentials in the process.[/quote]The link in my edited post doesn&#039;t work for you? Works for me. [quote=&quot;pid:58221, uid:28772&quot;]AVG was a problem for me years ago, and was very difficult to get completely uninstalled. IIRC, its email shield would not uninstall if it was enabled when AVG was uninstalled. I think I had to use an AVG removal tool. A quick search found two:[/quote]Used AVG Clear tool again (had used it the previous time) and no change in action with PMail. I&#039;m actually getting a new machine delivered today for unrelated reasons. Going to get that one up and running and first application install will be PMail for a test.
edited Nov 9 '25 at 7:47 pm

The link in my edited post doesn't work for you? Works for me.


Sorry, I didn't look back for an edited post.


Nothing jumps out at me in the session log that would explain the slowdown but analyzing these logs is not one of my strengths so I'm hopeful some spots something that I don't.


[quote=&quot;pid:58227, uid:38982&quot;]The link in my edited post doesn&#039;t work for you? Works for me.[/quote] Sorry, I didn&#039;t look back for an edited post. Nothing jumps out at me in the session log that would explain the slowdown but analyzing these logs is not one of my strengths so I&#039;m hopeful some spots something that I don&#039;t.

I didn't see anything wrong either. Considering only the date and time stamps, it took about 3 minutes to send the message. I think that's a reasonable time, especially because of the AVG proxy.


I didn&#039;t see anything wrong either. Considering only the date and time stamps, it took about 3 minutes to send the message. I think that&#039;s a reasonable time, especially because of the AVG proxy.

-- Euler

Pegasus Mail 4.91.1746 Windows 7 Ultimate
IERenderer: 2.7.3.5 AttachMenu: 1.0.2.0
PMDebug: 2.5.8.37 BearHTML 4.9.9.6

I didn't see anything wrong either. Considering only the date and time stamps, it took about 3 minutes to send the message. I think that's a reasonable time, especially because of the AVG proxy.
Thanks, euler.
AVG is not the problem, already ruled out.
The same email takes about 3 seconds on the other host, and Pmail remains functional while doing it.
This one is 60 times slower and PMail is rendered non-functional during that time.


I can't just stop work every time PMail chokes on an attachment. I send a lot of them. It's like you get a new phone, but it locks up for a minute or two every time you send an email and you're told it's not that long to wait.
Yes, I know. I can change hosts. Or live with it. Or wait to send all big emails at the end of the day. Our use a cloudhost for any attachment. Or spend 2 minutes chopping the big ones up into 20 tiny ones and drive my clients crazy on the other end stitching them all back together.


Or...
I can sort out what the heck the problem is and fix it. I'm at this forum to do that.


[quote=&quot;pid:58230, uid:2194&quot;]I didn&#039;t see anything wrong either. Considering only the date and time stamps, it took about 3 minutes to send the message. I think that&#039;s a reasonable time, especially because of the AVG proxy.[/quote]Thanks, euler. AVG is not the problem, already ruled out. The same email takes about 3 seconds on the other host, and Pmail remains functional while doing it. This one is 60 times slower and PMail is rendered non-functional during that time. I can&#039;t just stop work every time PMail chokes on an attachment. I send a lot of them. It&#039;s like you get a new phone, but it locks up for a minute or two every time you send an email and you&#039;re told it&#039;s not that long to wait. Yes, I know. I can change hosts. Or live with it. Or wait to send all big emails at the end of the day. Our use a cloudhost for any attachment. Or spend 2 minutes chopping the big ones up into 20 tiny ones and drive my clients crazy on the other end stitching them all back together. Or... I can sort out what the heck the problem is and fix it. I&#039;m at this forum to do _that_.

The same email takes about 3 seconds on the other host, and Pmail remains functional while doing it.
This one is 60 times slower and PMail is rendered non-functional during that time.
It seems to be a host problem. Maybe you should try using different hosts for sending (SMTP) and for retrieving (POP3). Do not forget to inform the address to which replies should go on Tools > Options... > Outgoing mail > Sending mail > Default "reply-to" address: or it may go to Sender:'s.


Some hosts don't like it though...


[quote=&quot;pid:58231, uid:38982&quot;]The same email takes about 3 seconds on the other host, and Pmail remains functional while doing it. This one is 60 times slower and PMail is rendered non-functional during that time.[/quote]It seems to be a host problem. Maybe you should try using different hosts for sending (SMTP) and for retrieving (POP3). Do not forget to inform the address to which replies should go on Tools &gt; Options... &gt; Outgoing mail &gt; Sending mail &gt; Default &quot;reply-to&quot; address: or it may go to Sender:&#039;s. Some hosts don&#039;t like it though...

-- Euler

Pegasus Mail 4.91.1746 Windows 7 Ultimate
IERenderer: 2.7.3.5 AttachMenu: 1.0.2.0
PMDebug: 2.5.8.37 BearHTML 4.9.9.6

I can sort out what the heck the problem is and fix it. I'm at this forum to do that.


I think we are at our wits end. There is nothing in the Pegasus Mail configuration that would throttle an SMTP connection and nothing in the log that identifies a problem. It appears that the connection is just slow. The fact that transmission is dramatically faster using the same port on a different host, indicates the issue is not with Pegasus Mail or with your connection capability. What's left except a problem on the host end?


[quote=&quot;pid:58231, uid:38982&quot;]I can sort out what the heck the problem is and fix it. I&#039;m at this forum to do that.[/quote] I think we are at our wits end. There is nothing in the Pegasus Mail configuration that would throttle an SMTP connection and nothing in the log that identifies a problem. It appears that the connection is just slow. The fact that transmission is dramatically faster using the same port on a different host, indicates the issue is not with Pegasus Mail or with your connection capability. What&#039;s left except a problem on the host end?

It seems to be a host problem. Maybe you should try using different hosts for sending (SMTP) and for retrieving (POP3). Do not forget to inform the address to which replies should go on Tools > Options... > Outgoing mail > Sending mail > Default "reply-to" address: or it may go to Sender:'s.
Part of the reason I switched to this host is I had to do just that using MS365 to get around other different issues. If I need to go to that level here just to send emails with attachments, I'd switch to another host. (My other smtp is a dormant domain that I occasionally use, that has it's own limitations for using it as my work URL host.)


I think we are at our wits end.

Yeah, so were we.


What's left except a problem on the host end?

A PMail coding issue yielding a bad reaction to something from/at/by/with the host directly or in combination with the OS.


Logically, it's the only viable explanation left given the data:


  • The host sees no problems on it's end in logs or messages from PMail (we worked together with screen share and live monitoring as the email sends.)
  • PMail logs no error in SMTP transfer, just occasional huge time gaps between packets
  • PMail locks up during the huge time gap
  • It happens exactly the same way from two different machines with the same PMail load (it also happened on an old version of PMail on the laptop before I upgraded to current PMail.)

Is there a debugging feature on PMail I can use to monitor the software behavior during the problem period? (not just the SMTP log?)


[quote=&quot;pid:58232, uid:2194&quot;]It seems to be a host problem. Maybe you should try using different hosts for sending (SMTP) and for retrieving (POP3). Do not forget to inform the address to which replies should go on Tools &gt; Options... &gt; Outgoing mail &gt; Sending mail &gt; Default &quot;reply-to&quot; address: or it may go to Sender:&#039;s.[/quote]Part of the reason I switched to this host is I had to do just that using MS365 to get around other different issues. If I need to go to that level here just to send emails with attachments, I&#039;d switch to another host. (My other smtp is a dormant domain that I occasionally use, that has it&#039;s own limitations for using it as my work URL host.) [quote=&quot;pid:58233, uid:28772&quot;]I think we are at our wits end.[/quote] Yeah, so were we. [quote=&quot;pid:58233, uid:28772&quot;]What&#039;s left except a problem on the host end?[/quote] A PMail coding issue yielding a bad reaction to something from/at/by/with the host directly or in combination with the OS. Logically, it&#039;s the only viable explanation left given the data: - The host sees no problems on it&#039;s end in logs or messages from PMail (we worked together with screen share and live monitoring as the email sends.) - PMail logs no error in SMTP transfer, just occasional huge time gaps between packets - PMail locks up during the huge time gap - It happens exactly the same way from two different machines with the same PMail load (it also happened on an old version of PMail on the laptop before I upgraded to current PMail.) Is there a debugging feature on PMail I can use to monitor the software behavior during the problem period? (not just the SMTP log?)
edited Nov 10 '25 at 7:39 pm

PMail locks up during the huge time gap
It happens exactly the same way from two different machines with the same PMail load (it also happened on an old version of PMail on the laptop before I upgraded to current PMail.)


This actually isn't a lock up. The Pegasus Mail code remains single-threaded so it appears to "hang" when it is busy. In your case it is busy trying to transmit. The same appearance of a hang can occur during POP3 retrieval of large message or when checking numerous hosts.


Is there a debugging feature on PMail I can use to monitor the software behavior during the problem period? (not just the SMTP log?)


There is a MiniDump extension that was originally created as a hard crash debugger but it now also contains a "Snapshot" tool designed to record the status of Pegasus Mail during a hang. That extension might be worth a try. Its developer is active on this forum so he may contribute thoughts on this. That extension is available here: https://www.pmpgp.de/pmtools/MiniDumpAndSources.zip


[quote=&quot;pid:58234, uid:38982&quot;]PMail locks up during the huge time gap It happens exactly the same way from two different machines with the same PMail load (it also happened on an old version of PMail on the laptop before I upgraded to current PMail.)[/quote] This actually isn&#039;t a lock up. The Pegasus Mail code remains single-threaded so it appears to &quot;hang&quot; when it is busy. In your case it is busy trying to transmit. The same appearance of a hang can occur during POP3 retrieval of large message or when checking numerous hosts. [quote=&quot;pid:58234, uid:38982&quot;]Is there a debugging feature on PMail I can use to monitor the software behavior during the problem period? (not just the SMTP log?)[/quote] There is a MiniDump extension that was originally created as a hard crash debugger but it now also contains a &quot;Snapshot&quot; tool designed to record the status of Pegasus Mail during a hang. That extension might be worth a try. Its developer is active on this forum so he may contribute thoughts on this. That extension is available here: https://www.pmpgp.de/pmtools/MiniDumpAndSources.zip

That extension might be worth a try. Its developer is active on this forum so he may contribute thoughts on this.

Yep, it's worth a try.


[quote=&quot;pid:58235, uid:28772&quot;]That extension might be worth a try. Its developer is active on this forum so he may contribute thoughts on this.[/quote] Yep, it&#039;s worth a try.
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C
12
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft