• This time there are three major changes in this version:

  1. I've implemented a relocation of the default IER file cache location (if not having been customized previously) which will be applied automatically if confirmed on first launch after updating: The cache directory will now be a subdirectory of the respective Pegasus Mail user's new mail directory for ensuring that it will stay the same location when using Pegasus Mail on portable devices or networks. Please note that copying existing cached files to the new location may slow down the first Pegasus Mail launch after updating IER once for each Pegasus Mail user!

  2. Next one is an extended menu option for changing Pegasus Mail's HTML renderer: It now offers additionally the option to use Pegasus Mail's internal RichText module as HTML renderer which may be helpful for a couple of Windows XP and Linux users: While BearHtml will be enabled by default if detecting MSHTML modules of IE versions below v8 they may now easily switch to the built-in renderer if regarding it to serve their requirements better. It should be capable of restoring itself even after updates trying to restore renamed files for applying these changes. Please note that switching to and from the built-in renderer will require a restart of Pegasus Mail which will be offered as an immediate option after selecting the respective switch.

  3. Another important change is the migration of image processing from using the system's GDI+ interface to the favour of the open source FreeImage library (already coming with Pegasus Mail) which might speed up HTML rendering a little bit if loading embedded images.

• This version also brings a slightly modified handling for the BearHtml related crash of the previous version for taking care of yet unknown reasons to cover.

• Additionally it includes slightly modified help files for better readability and some adjustments with regard to required Windows versions and also fixes and removes some outdated URLs.

• Then it fixes a workaround dealing with improper use of HTML 5 elements in supposedly IE 11 compatible messages which accidentally would hide images.

• It as well fixes a charset issue affecting HTML text imported into Pegasus Mail's editor from external HTML files if containing non-ASCII characters in UTF-8 and local ANSI encoding.

• And it finally works around an issue caused by invalid size formatting of embedded emoticons in notifications from Pegasus Mail's support forum.

Michael,

After installing IER 2.7.2.0, when I open PM and close it normally, the next time I open it, it's showing the dialog indicating that the mailbox is locked. I reverted back to 2.7.1.13 and the problem goes away.

I am running on a network, but chose to not move the cache location on first launch after installing 2.7.2.0. I prefer to keep the cache location on my local drive as I only use PM from this desktop.

With 2.7.2.0 installed, watching in Task Manager when exiting PM, I see a second instance of PM starts and closes while closing PM. That does not happen with 2.7.1.13.

How do I get it PM close normally and remove its lock file on exit with 2.7.2.0 installed?

Regards,
Tony

I don't know, this may only happen once, did you try to start and close Pegasus Mail a second time after updating? The only reason for starting a second instance on close would be after switching renderers, but this should only happen once after doing so and being announced by a dialog. It's not related to the cache location.

PS: Anything else could be caused by a crash, please install my Minidump extension (https://www.pmpgp.de/pmtools/MiniDumpAndSources.zip) in such a case and provide crash dumps, preferably running Pegasus Mail via the Pegasus Mail Debugger entry its Installer creates in its Start Menu Group.

After further investigation, it appears to happen when I open PM and don't open any messages. I use list mode. If the new mail folder is empty, and I close PM, or if I open PM and decide I don't need to look at any of the messages, I get the mail box locked dialog on next open.

That said, I just tried it with Preview mode enabled and it seems to close and re-open normally as long as there is at least one message in the new mail folder. With Preview mode enabled, if the new mail folder is empty, and I don't open any messages, it also exhibits the "new" behavior.

Regards,
Tony

That's weird, and unforatunately I can't duplicate it, at least not on Win10 with a non-network setup.

It happened to me. No network. Windows 11 Pro.
I saw the splash of a dialog that I think said "Writing dump file" but I have not yet installed minidump on this PC so I'm clueless about this. I can't find a file the file, if one was created.
I am five days into a five week cross-country car trip so am a bit limited in my ability to troubleshoot and be responsive but I'll do what I can.

My second shutdown try resulted in an endless dump file creation loop by minidump. Dump files have been located and forwarded to Michael.

Edit: FYI, my experience is the same as reported by @TonyQuick in that shutdown is normal as long as I open at least one message (only tested with new messages).

I would recommend to remove or rename the MiniDump.fff file and test again without it for a start. I've just taken care to upload a recompiled version of the MiniDump tool using the same basic code as IER does to have comply with all the latest Pegasus Mail versions so further tests with it should avoid any MiniDump crashes to cause any additional issues.

@TonyQuick : If you should have a older version of the MiniDump tool installed you might want try to either update or uninstall it as well for figuring out whether it helps in fixing the shutdown issue.

Yes.

Shutdown issue still exists when MiniDump is disabled. The only abnormality I have noticed is that there is processing activity during shutdown that seems longer than what had been normal. I'll test with new MiniDump when I can.

I sent two dump files to Michael that were created by the newest MiniDump. Unfortunately, they may be as useless if that is typical in shutdown crash cases.

I'm signing out and getting back on the road. Hope to be back when we stop for the night.

@idw Minidump is not installed here.

Also duplicated problem with Windows 10 Pro. Thought I should try it since Brian and I are using Windows 11 Pro and Michael said he couldn't duplicate it on Windows 10. So it's not specific to Windows 11 Pro or network...

FWIW, I just tested IER 2.7.2.0 in my second instance of Pegasus Mail (current beta) and the shutdown crash is not occurring.

This is all very mysterious, especially since IER doesn't have any direct impact on shutting down Pegasus Mail except for the one case of switching renderers. The only thing I did for this version since I thought it might not have any noticeable effect anymore on today's fast systems is something I added for people complaining about Pegasus Mail taking soooo long when shutting down: I added two lines of code for hiding Pegasus Mail's main window while doing its cleanup on shutting down. I've now readded those lines and compiled a test version of it which I'm uploading to a location of which I'm going to send both of you a download URL via email for testing: The ZIP archive will only contain the library file to replace the one included in the 2.7.2.0 version file, it'll, of course, be signed and have a version number of 2.7.2.1.

BTW, @BrianFluet: Both your dumps just showed MiniDump terminating after closing its progress dialog, so I assume it couldn't bring up its final report dialog anymore before terminating.

The new IERenderer.dll file solved the problem for me, confirmed by testing twice with old and with new to confirm that old crashed, new didn't.

Did not test on my beta installation since it was not exhibiting the crash behavior.

I'm surprised that there have not been any other reports of the crash on the support sites.

The new version 2.7.2.1 dll also resolved the problem here.

Thanks Brian, that's good news although still confirming the weird nature of the crash, but at least an easy to apply solution. Another background information is that David Harris encountered something similar when working on his recent betas asking me wether IER would be triggering any premature termination and unloading of libraries (in this case IER itself) since he saw issues on closure as well in his own testing - but these didn't affect v4.81 or any other older versions.

PS: Don't be surprised if getting another update notification for the same version, IER's version test only checks time intervals expired since uploading against its signature's time stamp since I cannot read the time stamp of the installer's signature on the download server.