Memory Leaks in IE8 and IE9 (Fixed in IE10)

In June 2007, Microsoft famously fixed a problem with memory leaks in Internet Explorer 6. IE8 leaks memory worse than IE6 ever did, yet I haven’t been able to find any mention of it. I say worse because:

  1. No closures or circular references are required.
  2. I cannot find a workaround. (Update: See comments from May 9, 2011 for a way to avoid the problem.)

Update: It was fixed in IE10.

Problem statement

The memory used by IE8 to create certain DOM nodes is never freed, even if those DOM nodes are removed from the document (until window.top is unloaded). There are no closures or circular references involved.

The DOM node types that leak are form, button, input, select, textarea, a, img, and object. Most node types don’t leak, such as span, div, p, table, etc.

This problem only occurs in IE8 (and IE9 and IE10 preview). It does not occur in IE6, IE7, Firefox, or Chrome.

In case you missed it: every image element, anchor element, etc. added to a page uses memory that is not reclaimed even if the element is removed from the page.

In practical terms

Think intranet web application rather than Internet web site—that is, something that you may leave running for multiple days. If you have a web page that never reloads as a whole but pulls over many updates from the server (e.g., images and anchors are updated Ajax-style), each update will leak memory. Note that update here means existing DOM nodes are removed and new DOM nodes are created.

Depending on the size and frequency of the updates, IE8 can end up using all available virtual memory, start thrashing within itself, and eventually failures occur; see below for more details.

The user hitting F5 occasionally (if the page can handle it) will unload window.top and free its memory, but there is no apparent programmatic workaround. If the page is in an iframe, unloading the iframe has no effect. It seems that window.top must be unloaded.

In terms of code

First example

Here’s the basic idea of the leak, which is to repeatedly execute the following:

function leak1() {
    var node = document.getElementById("TO_AREA");
    node.innerHTML = "<img>";
    node.innerHTML = "";
    node = null;
}

Notes:

  • You can leave off the second innerHTML assignment, as well as setting the node to null, which I put in just for clarity/emphasis.
  • There’s an initially empty div with an id of TO_AREA in the body.
  • Example innerHTML that doesn’t leak: <span></span>. See the problem statement above for a list of problematic node types.
  • As I mentioned, there are no closures or circular references involved here.

Second example

Here’s a similar piece of code that avoids innerHTML and has the same leak:

function leak2() {
    var node = document.getElementById("FROM_AREA").cloneNode(true);
    node.id = "NEW_AREA";
    document.body.appendChild(node);
    document.body.removeChild(node);
    node = null;
}

Notes:

  • The FROM_AREA contains HTML like in the first example. Still, there are no closures or circular references.

Third example

This is the simplest and most straightforward:

function leak4() {
    var node = document.createElement("IMG");
    document.body.appendChild(node);
    document.body.removeChild(node);
}

Replace IMG with (e.g.) SPAN, and there is no leak.

Other notes

These examples leak in IE8 but not other browsers. I’ve tried IE8 on Windows XP, Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7. I’ve tried IE in IE7 backwards compatibility mode, as well as every possible variation of quirks and standards mode. Though that’s by no means every variation of everything, it makes me comfortable that it’s not a fluke.

Live example

Here’s a link to an example page that shows the problem highly amplified. What I mean by amplified is that the job of the page is to show the leak, highly exacerbated; it has no other purpose. There are start/stop links on the page, so don’t worry about the page doing something terrible on its own.

http://test.hemiola.com/leak-ie8.html

Characterizing the leak

The memory size (called private working set on Windows 7) of iexplore.exe grows steadily over time, but this doesn’t lead directly to failures. IE memory usage does seem capped, and it does seem to be trying to manage memory from a DHTML perspective within certain constraints.

After it reaches its self-imposed cap, it seems to start thrashing within itself. Operations that could be performed at maybe 100 times per second begin taking over one minute per operation. Eventually, DHTML-style out-of-memory errors can occur.

In closing

I’m very interested in hearing about workarounds to this problem. I will post any meaningful updates as they are uncovered.

Update 2010-03-26

Microsoft made an IE9 preview available on 2010-03-16. It runs my leak test and does not leak. This is very promising. Additional update on 2010-06-24: We are now up to preview #3, and still no leaks.

There is a lot of memory churn in IE9 for the elements that leak in IE8, and there’s no churn at all for elements that don’t leak in IE8. The memory usage pattern in IE9 could be characterized as following a sawtooth pattern (low amplitude, high frequency), but with no long-term growth. I ran the test for an hour with no memory growth in IE9, whereas IE8 grew by about 1 GB in the same time.

Update 2010-09-16

Microsoft released the first beta of IE9 yesterday. The leak is back, at a rate of about 1 GB an hour: the same elements are leaking as before, at about the same rate as before.

Update 2010-10-28

Microsoft released the sixth preview of IE9 today. The leak is still there, same as in the beta.

Update 2010-11-17

Microsoft released the seventh preview of IE9 today. There’s the same churn and sawtooth as in the original three previews, and likewise, there is no leak. This is turning into a nail-biter.

Update 2011-02-10

Microsoft released the IE9 RC today. The leak is back.

Update 2011-03-14

Today is π Day, and Microsoft released IE9. The leak is still there.

Update 2011-04-12

Microsoft released IE10 Platform Preview 1. In terms of leaking, this is very similar to the IE9 preview: no overall leak, but a lot of churn and the sawtooth pattern is back.

Update 2011-06-29

Microsoft released IE10 Platform Preview 2. No leak. I suppose there is no SmartScreen Filter in these preview releases, which might account for the leak being absent from them.

Update 2011-09-13

Microsoft released the IE10 Platform Preview 3 as part of the Windows 8 Developer Preview. The leak is still there if the SmartScreen Filter is off; otherwise (the default), the leak is not there.

Update 2011-11-29

Microsoft released the IE10 Platform Preview 4 for the Windows 8 Developer Preview. The leak is not there, but I suspect the SmartScreen Filter is also not there; it’s hard to tell.

Update 2012-02-29

Microsoft released the IE10 Platform Preview 5 for the Windows 8 Consumer Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best it’s looked in years.

Update 2012-05-31

Microsoft released the IE10 Platform Preview 6 for the Windows 8 Release Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best IE has looked in years. And Windows 8 is looking pretty good, too (after going to the desktop and staying there, that is).

Update 2012-11-13

Microsoft released the release preview of IE10 for Windows 7. The leak is back, just as before: with the SmartScreen Filter disabled, the leak is present; with the SmartScreen Filter enabled, the leak is not present.

Update 2013-02-26

Microsoft released IE10 on Windows 7. The leak is gone! With the SmartScreen Filter enabled, the sawtooth pattern is there. With the SmartScreen Filter disabled, it looks even better: no manic memory usage and no memory growth.

Update 2013-06-26

Microsoft released an IE11 Preview with the Windows 8.1 Preview. I haven’t had a chance to look at it.

Update 2013-07-25

Microsoft released the Developer Preview of IE11 for Windows 7. It looks fine.

46 thoughts on “Memory Leaks in IE8 and IE9 (Fixed in IE10)

  1. Joel Webber

    Definitely an interesting find; thanks for pointing it out.

    I haven’t had a chance to try this out yet (my windows box is at the office) — have you tried any cases that involve only DOM manipulation, but with no innerHTML or cloneNode()? Not that it would make it all that much better, but might shed some light on the source of the problem.

    Reply
  2. Jens-Ingo Farley Post author

    Do you mean something like this?

    function leak4() {
    var node = document.createElement(“IMG”);
    document.body.appendChild(node);
    document.body.removeChild(node);
    }

    Yes, this leaks at the same rate. Replace IMG with (e.g.) SPAN, no leak.

    (I updated the post to include this example.)

    Reply
  3. Joel Webber

    How unfortunate. I guess the only good thing we can say about this leak is that at least it leaks somewhat slowly. But you’d think that in almost 2010, we would be building software on tools that don’t randomly leak memory in ways you can’t control :P

    Reply
  4. KD

    I found this post while trying to find a solution to a horid memory leak issue I’m dealing with myself. The problem is occurring during a loop where table rows are being sorted and appendChild() seems to be the culprit. The leak is so bad that IE8 uses all available memory on the machine and crashes IE8.

    I’ve put up a detailed post (along with example page) here:

    http://forums.asp.net/p/1513032/3611111.aspx#3611111

    If anyone could help me find a possible solution I would be forever grateful.

    Reply
  5. Fogtower

    Hi, Thank you for your research.
    Last week, I found a problem in IE8, when I remove tr and add another tr, mem in IE8 will increase. At last I found your blog, saw the article, maybe I found the reason.
    So I want to translate your article to Chinese, so more Chinese developer will see your research result.
    Now I don’t finish it, please wait for some days.

    Reply
  6. Jens-Ingo Farley Post author

    @Fogtower, my findings actually conclude that tables (table, tr, thead, and td elements) don’t leak. I listed all the elements that leak (in the problem statement), and you can try them out on my test page (in the live example). However, it sounds like you might be experiencing a different issue.

    I’m sorry I don’t have a solution or workaround to the problem, but thank you for your interest in translating the article.

    Reply
  7. Tracy Otto

    I you found a solution to this. I have an internal website that has a similar situation, but the hyperlink (<A>) is inside a cell. when the <A> is leaked, it leaks the entire table, beacuse the A is holding on to the cell which in turn holds on to the row, and then the table, which is where I drop it out of the DOM. This maybe what Fogtower was encountering when talking about leaking tr’s.

    Reply
  8. De Lurk

    Hello everybody
    Let me first say thank you for this blog entry. Very cool.
    I was in the same situation like some of you hunting for memory leaks. I do not start saying negative things about IE memory leaks – the text would be long.

    Well, I tried some things and found a solution for my specific problem but it may help you too. I had to remove an IMG tag from the loaded page by javascript:
    On the page was a

    According to DRIP v0.5 this leaks in IE v8.0.6001.18702 :

    var childtoRemove = document.getElementById(‘imgStart’);
    childtoRemove.parentNode.removeChild(childtoRemove)
    childtoRemove = null;

    This leaks not :

    var childtoRemove = document.getElementById(‘imgStart’);
    childtoRemove.clearAttributes();
    childtoRemove.parentNode.removeChild(childtoRemove)
    childtoRemove = null;

    IE needs clearAttributes() !!!!!!!!!!!!
    IE is good, we are dumb. Or so…..

    Best regards
    De Lurk

    Reply
  9. Jens-Ingo Farley Post author

    @De Lurk: Interesting, but I had tried that, and it didn’t help. I suspect that in your first case, you are seeing a huge leak, and in your second case, you’re still seeing a small leak — perhaps small enough for you to be able to ignore in your case. The nature of the problem I’m describing here is a longevity issue, for a web application that may be left up for over a week at a time. At any rate, I’m not too worried now that the problem has been fixed, at least for now, in IE9.

    Reply
  10. De Lurk

    Perhaps my work around works only on an image, perhaps only with the attributes I used or even worse depends in which tag the element is placed. I had a element with an image inside.
    I admit, I did not test it with a loop. I saw only, DRIP no longer issued a memory leak message regarding my IMG element.
    We also have a long longevity web application. I startet with an easy bug. The Ajax errors are still to do…. sigh…

    Reply
  11. Steve Down

    I’m afraid it can be even worse – my application keeps growing iexplore.exe even on repeated page reloads – so I can hit F5, wait a minute, hit it again, repeat, and watch private working set grow…

    Reply
  12. Peter Hayhurst

    I have a similar problem using ie8 in a vb6 web browser control. Basically I create a a table dynamically using jscript
    with the methods createElement and appendChild. As each row is added more memory is used. When i quit the web browser control the memory stays allocated to the program. When the program is ended the memory appears to be released.

    Interestingly the table does have images in it.

    Reply
  13. Reuben Sivan

    Thanks for this very useful blog.
    I just tried the link above, and I found no leaks in my IE8 environment.

    I wonder if one of the following might explain why the failure to leak memory in my system:

    1. I am running on Windows 7/64 (tried on both IE8/32 and IE8/64)
    2. I am running IE 8.0.7600
    3. Other reason?

    Thanks

    Reply
  14. Jens-Ingo Farley Post author

    @Reuben Sivan: Though it’s true I have not tried 64-bit Windows 7, I doubt that’s a factor. I’m running IE 8.0.7600. Are you sure you observed the correct iexplore.exe in Task Manager? You get two to start with, and then more if you have more than one tab or browser window. If you run the test for at least 7 minutes or so, you should see one iexplore.exe go over 100,000 KB, which should be easy to spot (especially if you’ve sorted by “image name”).

    Reply
  15. Steve Bohne

    In my experience, turning ON “Enable SmartScreen Filter” in Advanced Internet Options will workaround this leak. After enabling the option I no longer see the leak on the test page, at least with img tags. Didn’t try any other tags.

    Tools->Internet Options->Advanced Tab
    Check “Enable SmartScreen Filter” and click OK.

    Then try http://test.hemiola.com/leak-ie8.html

    Would be interested to hear if this works for anyone else.

    Reply
  16. Jerome PETIT

    Hi,

    we found that turning on “Enable SmartScreen Filter” in IE8 seems to be fixing the leak.
    This setting is under Advanced Options right before the use SSL 2.0 and 3.0 checkboxes

    Reply
    1. jkestler

      Hi,

      Just tried turning on “Enable SmartScreen Filter” in IE8 on an XP Pro machine. Does not stop the leak for me. Bummer, but thanks for doing the research on this one, much appreciated.

      Reply
  17. Jens-Ingo Farley Post author

    Steve and Jerome: Wow! It’s been about 1.5 years of leaking without a known workaround, and yes, that workaround works for me. It’s unfortunate that you have to turn on the SmartScreen Filter (i.e., send URLs over the Internet) to avoid the leak. And not to discount the wow factor, but I don’t see any correlation or have any intuitive insight into why there is a DOM-related leak sensitive to this setting.

    I’m no longer working on the project where I discovered this leak, but an important use case at the time was running the UI on a system with no Internet access — e.g., in a data center that’s behind a firewall with no web proxy. I don’t have the environment to try that out now, where I would have the SmartScreen Filter enabled but no Internet access thus no filtering would be possible. I wonder if the leak would stay away in that case.

    In any event, thank you very much for the workaround! Again, wow.

    Reply
  18. Greg

    Thanks for the updates. I found that IE 9 performed so badly that I had to go back to IE 8. This was not too bad but the memory leaks now are killing me and making it unusable. Was there a recent patch that causes this? The reason I ask is that I did not have many problems a few months ago and then suddenly I have had problems for about the last 3 weeks.

    Reply
    1. Jens-Ingo Farley Post author

      I can only speak to the issue correlated to the SmartScreen Filter (described above). The only leak I’ve experienced is not related to any patches and is worked around by turning *on* the SmartScreen Filter (yes, that’s a bit counterintuitive).

      Reply
  19. Dave

    I don’t need to run any apps to see my memory leak, it’s much more simple than that. All I need to do is a Google search and I can watch the usage grow. Everytime I search it goes up by 1-2k. I left IE8 up for a few days and just went about my normal business, which is basically using it for Google searches, and within 3 days IE was using over 400,000k in Task Manager. I’ve tried the workaround mentioned above and it makes no difference. Unfortunatly, I’m stuck using IE, at least at work.

    Reply
  20. Brian

    :( I was looking for a possible solution for this for my computer (XP IE8), as I regularly experience odd memory leaks in IE8 as I move about the web. I read through all these comments and checked out my settings for SmartScreen Filter and it’s already been on this whole time; so it hasn’t been helping in my case….

    Reply
  21. Anony Mole

    I don’t know if this site has anything to do with it – but while messing around with IE8 and the smartscreen filter (on/off) and testing on the IE8.html test page – I got hit by the “Recovery Data” virus! Took me 4 hours to recover…

    Reply
    1. Jens-Ingo Farley Post author

      test.hemiola.com looks clean to me. It’s true that about five years ago, my hosting service had a backend PHP virus of some kind that rampantly modified .htaccess files to redirect browsers to downloadable malware, but everything looks clean now.

      Reply
  22. LOVE_MOSS_NOT

    VERY USEFUL INDEED, THANK YOU..

    C’MON M$, YOU WANT THIS WIN8 TO WORK OR WHAT?
    FIX THE LEAKS, LEARN FROM CHROME, OR THROW THE
    TOWEL AND JOIN WEBKIT OR FIREFOX.

    ACTIVEX = BINARY = DEAD = SILVERLIGHT = THE WEB MUST REMAIN TEXT.

    Reply
    1. Jens-Ingo Farley Post author

      Though the leak described here was in the early preview releases of IE10 (and in IE9, and in IE8), it is finally not present in IE10 on Windows 8 Release Preview.

      Microsoft is going with all caps in the menu in Office and Visual Studio (and probably everything else). That looks frighteningly bad.

      Reply
  23. Bob

    One workaround -
    I’m running the free “Extended Task Manager” from Extensoft but some other task manager might do the same job.
    1. Go to the “Processes” tab and select any iexplore.exe processes that are using a lot of memory (could sort on the memory usage column).
    2. Right-click and select “End Process”.
    3. Answer “Yes” to the warning about terminating the processes.
    The selected processes (tabs) will be terminated but IE8 “recovers” them with the memory leaks freed – nice.
    If you look at the “Performance” tab, you will see the memory usage drop.

    Reply
  24. Stuart

    This is a great post and thanks for the updates on each browser version too. This is a great resource!

    Does anyone know if this has a Microsoft Knowledge Base number or if it has been submitted as a bug with Microsoft?

    Reply
  25. Pingback: Testování v reálných podmínkách | Jan Lender

  26. Bear

    thanks for your tracking this issue! it is so helpful. i also tracking it for years! hopefully it gone with IE 10.

    Reply
  27. Stuart

    I have some news that I hope will help to resolve this. In the application that I have been working on we experienced a memory leak in Internet Explorer 8, 9 & 10 and contacted Microsoft through a support call. It’s been a very helpful process.

    The leak we have seen is to do with parentNode.removeChild( node ) not releasing memory. I was able to create a sample test case that automatically replaced the content of the page through AJAX. This was done with the JSF technology that we use in our application as a basis.

    Microsoft found that the removeChild() method was leaking memory and they have told me that in IE11 this bug should be fixed. The bug they considered severe enough to ‘backport downlevel’, which basically means in older releases. The request has been made to put the fixes into IE9 & 10, but there are a few more hoops for them to jump through before we know if the problem will be fixed.

    The workaround that we were able to use in our case was actually very simple. We created a div element that we hid from view to act as a garbage collection.

    In all the locations in our code where removeChild() was used, we then altered the code to read as follows.


    var gc = document.getElementById('garbage-collector');
    gc.appendChild( parentNode.removeChild( childNode ) );
    gc.innerHTML = '';

    The important thing to realise here is that the removeChild() method returns a reference to the removed child, which we then place into our garbage collection element. In order to remove the element without then calling removeChild() which leaks, we alter the HTML directly to blank the content of the garbage collector. By doing this, Internet Explorer is able to release the memory for element attributes and event listeners in a cleaner fashion and the memory leak is circumnavigated.

    I realise this methodology might not work for everyone, but it had a very severe impact on our memory retention in our own application. I hope it helps someone else too.

    Reply
    1. Jens-Ingo Farley Post author

      I think we’re branching away from the original problem I had in 2009, in IE8, which appears to finally be fixed in 2013, in IE10. The original problem occurred when clearing innerHTML and avoiding removeChild(), or using removeChild(); it didn’t matter. Perhaps you’ve found a new problem, where the workaround is to use the very technique that would have had the leak described here if it had not been fixed in IE10.

      At any rate, thanks for your explanation. I’m sure others will benefit from having the information out there.

      Reply
  28. Cody Casterline

    I found your very thorough writeup and was excited because it seemed to explain a problem one of my customers was running into. (They click around on pages where we load/unload images and eventually performance degrades enough so that the browser tab just becomes unusably slow and hangs.)

    Unfortunately, after further testing it seems that maybe MS has fixed this issue in IE8? (Unfortunately for me, I say, because now I have to look elsewhere to lay blame.) :p

    I’m running your leak-ie8.html right now with IE 8.0.7600.16385. It’s up to 13,000 iterations and the memory usage is still < 6MB. (I was worried maybe I was looking at the wrong process ID, but my system memory usage is flat as well.)

    Reply
    1. Jens-Ingo Farley Post author

      I’ll do that. It was leaking in IE10 before it was released, but that doesn’t matter anymore.

      Reply
  29. Martin Franke

    First off, thanks for the enlightening post!

    Tried it myself because I will have to deal with IE8 mem leaks in single-page apps, eventually. Since this thread doesn’t appear to be dead I wanted to share my results. (Tests done in VMware, if that might matter. SmartScreen Filter is OFF.)

    Win7 64bit:
    IE8 8.0.7601.17514: leaks, 6.5MB -> 86MB after 23000 iterations (no newer IE8 via Windows Update for me)
    IE9 9.0.8112.16421: leaks, 10.2MB -> 88MB after 22000 iterations (no newer IE9 via Windows Update for me)
    IE10 10.0.9200.16618: no real leak, going up from 5.9MB to 6.9MB over ~20000 iterations, then dropping back (garbage collector?), repeat (stopped after 120000 iterations)

    WinXP SP3 32bit:
    IE8 8.0.6001.18702: stable at ~16.5MB -> NO LEAK (ran it 2 times, stopped after 21000 and 45000 iterations, respectively)

    Findings:
    - IE8 on WinXP looks like it has been fixed!
    - IE9 performs better than IE8 — it leaks much faster ;)

    Reply
        1. Jens-Ingo Farley Post author

          I powered up an old laptop running WinXP x86 SP3 and IE8, got all the latest updates, tried my test, and it leaked for me. I guess there are other variables.

          Reply
  30. Arivu

    Thanks for your detailed post!
    I tested with Win7 64 bit IE9 (9.0.20) on various machines, got the memory leak except one where I installed IE10 some time back and uninstalled latter. May be IE10 fixes related to this fix solved this issue in IE9 ?!

    Reply
  31. Pingback: jQuery (2.0.2) empty() html() Memory Consumption Continually Grows | Technology & Programming

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>