User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1201.0 Safari/537.1 Steps to reproduce: I am running TB 13.0.1. I have 3 add-ons (keyconfig 20110522, Lightning 1.5.2, Oracle Beehive Extensions for Thunderbird 1.0.0.5), but I have tried this with the add-ons disabled. I have 1 account configured in Thunderbird. It uses IMAP over SSL/TLS (port 993) to receive/view mail, and SMTP over SSL/TLS (port 465). I have an HTML signature that contains an URL referenced image file. 1. Click "Write" toolbar button 2. Enter destination address (problem occurs on any address, but for testing I will send to myself) 3. enter subject "Test sending email" 4. enter body "Test sending email", note that the signature is present below the message 5. Click "Send" toolbar button I have also tried this without a signature and get consistent results. I have also turned on logging and have attached the section of the log that occurs when I send a message. Note that it appears the TB hang occurs before the logging. I have corporate enforced AV and disk encryption from McAfee. I don't see in McAfee where the AV is configured to scan TB. This occurs regardless if I am connected to a VPN or not. Actual results: Notice the thunderbird.exe process consumes an entire CPU for ~5 seconds. It shows 25 on my machine which is a dual-core with 2 threads per core (4 threads total). Notice that thunderbird is locked up for a few seconds, I can't select the main TB window. Notice after 2-5 seconds the "Sending" dialog appears. Once the sending dialog appears I can switch to the main TB window and use it again. Expected results: Thunderbird should not consume an entire CPU. Thunderbird should remain "responsive", and the main TB dialog should not be locked up.

I also want to note that I did read these other bug reports: 538283, 189738, and 364916 538283 seems very close to my problem with the exception that it appears that bug was related to an attachment, which mine does not appear to require an attachment to reproduce the issue. Also, those bugs are marked as solved, and I am seeing this problem on the current release of TB. I forgot to mention, my machine is a laptop running Windows 7 x64. It has an "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz" with 2 cores and 4 total threads. I also have 8GB of DDR3 memory with about 4GB free. I have a 7200rpm disk with about 77G free.

Can you try clicking Send Later and then right-click the Outbox folder and "Send unsent messages". Is the CPU usage high too? Is there a progress bar in a dialog?

Depending on the response this may covered by bug 742697.

When I select "Send Later" from the File menu (or use the Ctrl+Shift+Return hotkey), I get the high CPU usage and TB becomes un-responsive. When I right-click on the outbox and click "Send Unsent Messages", TB CPU usage does increase, but only to 5-15% and the TB window remains responsive.

So, I set NSPR_LOG_MODULES=all:5,timestamp. I then started TB and created my test message to myself. I then waited for the logging to slow down (all the folder refreshes when starting up). Then I chose the option to "Send Later" and captured the log for that action. I did this twice. Attached are the logs. Note that I tried to sanitized them, replacing my email host with host.invalid.

another debugging log

I have upgraded to TB 14 and I still see this problem. Should I change the version of this bug report?

(In reply to rmccullough from comment #9) > I have upgraded to TB 14 and I still see this problem. Should I change the > version of this bug report? No need to.

(In reply to rmccullough from comment #4) > When I select "Send Later" from the File menu (or use the Ctrl+Shift+Return > hotkey), I get the high CPU usage and TB becomes un-responsive. > When I right-click on the outbox and click "Send Unsent Messages", TB CPU usage > does increase, but only to 5-15% and the TB window remains responsive. Please rule out problem like bug 389132 due to many garbage in Temp directory from your problem.

I deleted the temp files (there were ~3k of them) and it seems to be running much faster.