eMClient daily crashes - Windows memory leak

I posted about this several month ago, but the problem is getting worse. I believe it’s getting worse due to the size of my email Inbox. But I’m at a point of daily crashes with eMClient now.

Here is my original post:


I have a large email inbox, and I believe eM is loading all of the messages over time during a day. By the end of a day, the task manager is reporting 900+ MB of usage for eM most of the time. The crash most often happens for me when I’m creating a new email. It’s a resource problem. In the new email window, all of the buttons no longer have their icons, but instead have red-line x’s in them.

From that point, it’s not long before I get an exception window with my option being to try and continue (which won’t last long) or to quit eM. I can try to capture an image of this window the next time it happens, but I’m trying to avoid this by shutting down eM at least once a day and restarting. But I can rarely make it through a day of heavy eM use at this point…

I cannot believe I’m the only one having this issue?

I’m running in Windows 7 with eM version 7.1.31849.0

I had tried to revert to a previous version when this first happened, thinking it was the newer version that had the problem, but I still had the crash in the older version. Again I think it’s due to the number of emails in my inbox. I tend to keep and not delete them.

I would guess that nobody is experiencing the same problem Bryan.

Have you run a diagnostic on your computer memory. Most system BIOS have a utility to do that.

You say you have a large Inbox. What is the size of your database folder? You can find that by closing eM Client then getting the properties for the C:\Users[username]\AppData\Roaming\eM Client\ folder.

Rather than downgrading to an older version, have you tried upgrading to a newer one. There are more recent versions available at http://www.emclient.com/release-history

I have not specifically run any diagnostic, but the only crashes I ever get are with eM. This machine is very stable, it’s my home work machine that is used 12+ hours a day. It’s a 16GB Core i5, Win7 fully updated, virus protection/scanners, etc. It’s a fairly recent build.

The EM client folder you asked about is 4.41GB.

Interesting that eM has not suggested that I upgrade, I recall it doing so in the past. I will update to the latest version.

And I didn’t make it through the day before having a crash. Here is an example of what the format  bar looks like when this happens:

And here is the exception window that I get. I tried to open the Details, but you see what I got. No more details:

There was a similar post a couple of years back, but it is closed for new comments without any clear resolution. https://forum.emclient.com/emclient/topics/huge_memory_leak_in_emclient

But back to your post, memory problems can cause unexplained problems, so it is worth running a check.

I don’t think that 4GB is particularly large, and eM Client should handle that without a problem.

Hi Bryan,

From the UI glitch that displays in your New Mail window, I’d guess there is a problem with your database. That would link the issue with the extraordinary task usage. I’ll guide you how to start eM Client with a blank database.

  1. Create a backup of the current database in Menu > File > Backup
  2. If you have data stored locally in the local folders or in POP3 accounts, export this data in Menu > File > Export. You can also export the eM Client settings into .xml file
  3. Note that you have to close eM Client before making any changes in the database location, proceeding without closed eM Client can cause the program crash.
  4. Locate the database folder. It’s by default saved in: C:\Users%CurrentUser%\AppData\Roaming\eM Client
    To locate AppData folder you need to view hidden folders in Windows: https://support.microsoft.com/en-us/help/14201/windows-show-hidden-files
  5. Delete the eM Client folder.
  6. Starting eM Client again will create a new database. Now just set the accounts again and if needed, import the previously exported locally stored data and settings in Menu > File > Import.

I hope this will sort out the problem.

There’s definitely a memory leak issue with this app. I’m on version: 7.1.31849.0. As long as I let it start on startup the ram usage sky rockets to 80-90% usage in 10-15 minutes, together with Chrome and some 20-30 tabs. If eMClient stays off, I can idle at ~30% ram usage, which seems OK-ish (blame Chrome).

Interesting. Chrome is a serious offender and eM Client has a Chrome core. :-) 
I am using a much later version of eM Client, and it idles at 0% CPU and 120-130MB Memory. On my system that is less than 4%, which is totally acceptable. Maybe download the latest version of eM Client from http://www.emclient.com/release-history and see if there is any difference.

Yes, I won’t be surprised if it uses Chromium or something. Anyway, I updated to latest and we’ll see if the issue persists. I was under impression it updates itself to latest frequently, but apparently it does not.

Yes, it is a Webkit/Chrome core.

The automatic update does not notify for minor versions, which often do have important fixes.

Since I was the one who started this thread… I followed the suggestion from Russel above to deleting and rebuilding my database. After I did that, I additionally decided to archive a bunch of old emails, probably 2/3 of my inbox was moved to an archive folder.

After doing this, I have no experienced the memory explosion and GUI resource issues that I posted above. Thus I don’t know if it was the database rebuild or just shrinking the size of my inbox which helped, but for now at least, I’m not experiencing the runaway memory usage.

One other thing I noticed after doing the database rebuild. I previously would get a lot of Errors pop up in the Operations window. Now I only get those infrequently (previously I would get them once or twice a day). The message never told me much that seemed useful, but I did get a lot of them. Now, very rarely…

If my memory issue comes back, I’ll update here again. But for now at least, things are much smoother since the database rebuild…

You shouldn’t really take these imperative actions to fix the issue. The app should manage it.

Hi Bryan,

Thank you for the update on the issue. I’m glad that it worked because probably there was a minor glitch in the database that the program couldn’t recognise. So the database rebuild fixed it all.