Aug 11, 2017

The memoQ Web Search memory leak fix! (updated again)

A big thank you to Italian veterinary surgeon and translating colleague Claudio Porcellana, who solved the mystery of the memory leak which has plagued users of memoQ's Web Search for years now. While Kilgray developers busily work on alternative engines for fixing future versions, Dr. Porcellana used his head - as impatient Southern Europeans are wont to do.

The problem it seems is with troublesome Java applets on sites like Linguee. So he simply turned them off. And plugged the leak.

Kilgray currently uses an Internet Explorer component for memoQ Web Search, so here's the fix:
  1. Start Internet Explorer and open Internet options in the Settings:

  2. Go to the Security tab and click the Custom level button:

  3. Then find the Scripting section and disable the Java applets:

Leave Active scripting (= JavaScript, etc.) enabled or you will mess up the search for some sites like LEO.

After I made this change, I tested memoQ Web Search. Instead of the usual steady increase in memory consumption I used to observe due to the infamous leak, everything remained rock stable, and all my site searches that I typically use for legal and scientific translation worked just fine.

This fix ought to work with all versions of memoQ since the introduction of the web search feature (in memoQ 2013 R2 I think it was). So thank you, Dr. Porcellana, for making our working lives a little less crash-prone!

UPDATE: Further testing has revealed (as noted in some comments below) that there is more to the story. I was puzzled that some people continued to experience the memory leak unless "active scripting" was active, and at Varga's request I tested again on my system (I was sure up until then that his troubles might be tied to a Hungarian system, but it turns out that is in fact not the case). To9 my astonishment, the problem re-appeared after it had been eliminated before after disabling the Java applet scripting alone. I had to turn off "active scripting" too to achieve stability. And then suddenly the problem went away again.

Puzzling, right? And annoying of course. And then an idea occurred to me, and I dug up my Linguee user account password and logged in to Linguee under my user name. I contribute a lot of terms when I search in other browsers so I have a lot of credit, and this credit is applied as searches without ads.

It's the advertising. Some ads seem to involve Java applets. Other ads do buggy things with scripts that do not use applets. And some ads do neither of these two things and cause no trouble.

Maybe an ad blocker applied to Internet Explorer will fix the problem for memoQ Web search until the changeover to Chromium occurs in the next version. [No, it does not, alas.] In the meantime, I will achieve stability for today's big job by staying logged in to my Linguee account!

YET ANOTHER UPDATE: As advertisements and the like have been identified as the real source of trouble, one user suggested substituting the Windows hosts file. This approach has a number of advantages apparently; it presumably de-craps your Internet connection by blocking sites that send troublesome content, communicate with spyware, etc. A better hosts file with instructions for where to put it is found at:

Substituted hosts file on my Windows 10 system; the old file was backed up by re-naming it.


  1. Interesting. Why on earth would Linguee or just about anybody, anywhere use client-side Java? As far as I can tell, Linguee doesn't use it either. It could still be an IE bug that is related to this option, and somehow manifests on pages without Java. Anyway, we'll get rid of IE for our Web Search, as you have already learnt.

    1. Your guess is probably better than mine for this one, Gergely. An addendum to this matter which you might have noticed on the FB memoQ group is that there may be some cases where "active scripting" plays a role after all and ought to be disabled. At least that was the claim by a Hungarian translator who had already deactivated the Java applets. He said his search sites were "Glosbe, Linguee, ProZ, MyMemory (and also included Google search)", but I haven't had time to look further into the matter.

      In any case, whatever happens with future versions, there is now a "fix" of sorts that will work for anyone who has reason to work with older versions that are no longer supported. And it should take some pressure off the developers so the changeover need not be so pressured.

  2. I've just checked WebSearch behavior with memoQ 2015, 8.0 and 8.1 (using Windows 10), and in all cases the memory leak persisted when Linguee was added to the list of services even though the scripting of Java applets was disabled as you suggested. The only time the memory leak does not occur with Linguee with all of the memoQ versions above is when you disable Active scripting, regardless whether the scripting of Java applets is enabled or disabled, which I understand is a no-go with some services like LEO. So it seems to me that the fix to this problem will indeed be the replacement of the IE component with Chromium in memoQ 8.2.

    1. What version of the OS did you test, Varga? I use Linguee all the time, and just disabling the Java applets made memory usage rock-stable with my US English version of Windows 10.x. In the past I have seen strange incompatibilities of specific language variants of the Windows OS (particularly with versions of the German EASY archiving tools about 17 years ago), so I wonder if the Hungarian OS variants are a little different.

    2. Win10, US English.

  3. Hi, I am new with memoQ and did experience severe memory leaks as described here. I did have success with this solution:
    Basically: start memoQ with a low process priority. This has pretty much solved the problem. Happy Translating!

  4. The real update is that 8.2 has Chromium now, and the leak is gone.
    This part of the post is especially confusing:

    "Maybe an ad blocker applied to Internet Explorer will fix the problem for memoQ Web search until the changeover to Chromium occurs in the next version. [No, it does not, alas.]"

    Who doesn't do what? :) Did you mean to say no Chromium in 8.2 (which would be incorrect information), or that the ad blocker didn't help?

    1. The ad blocker for IE did nothing in the mQ Web Search versions that used IE. However, the customs Hosts file worked brilliantly, completely eliminated all the memory troubles I experienced in those versions.


Notice to spammers: your locations are being traced and fed to the recreational target list for my new line of chemical weapon drones :-)