Memory Leaks in IE8 (and IE9 and IE10)

32 Replies

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:

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

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.

32 thoughts on “Memory Leaks in IE8 (and IE9 and IE10)”

Joel Webber November 25, 2009 at 7:05 pm

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 ↓
Jens-Ingo Farley Post authorNovember 25, 2009 at 9:06 pm

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 ↓
Joel Webber December 2, 2009 at 12:23 pm

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

Reply ↓
KD January 12, 2010 at 6:22 am

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 ↓
Fogtower February 7, 2010 at 7:22 pm

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 ↓
Jens-Ingo Farley Post authorFebruary 7, 2010 at 10:09 pm

@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 ↓
Tracy Otto February 18, 2010 at 7:58 am

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 ↓
De Lurk June 24, 2010 at 11:49 pm

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 ↓
Jens-Ingo Farley Post authorJune 25, 2010 at 6:23 am

@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 ↓
De Lurk June 29, 2010 at 1:06 am

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 ↓
Steve Down July 27, 2010 at 5:59 am

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 ↓
Andreas K August 2, 2010 at 6:03 am

Steve, can you elaborate on that? Which application? Is it IE8? Also tested in IE9?

Reply ↓
Peter Hayhurst November 15, 2010 at 2:59 pm

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 ↓
Reuben Sivan February 7, 2011 at 1:54 pm

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 ↓
Jens-Ingo Farley Post authorFebruary 7, 2011 at 2:32 pm

@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 ↓
Steve Bohne May 9, 2011 at 12:53 pm

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 ↓
Jerome PETIT May 9, 2011 at 1:03 pm

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 March 23, 2012 at 5:14 am
  
  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 ↓
Jens-Ingo Farley Post authorMay 9, 2011 at 8:38 pm

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 ↓
Greg October 7, 2011 at 6:13 pm

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 authorOctober 7, 2011 at 6:21 pm
  
  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 ↓
Dave November 15, 2011 at 8:47 am

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 ↓
Brian January 30, 2012 at 6:57 pm

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 ↓
Anony Mole June 12, 2012 at 2:51 pm

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 authorJune 12, 2012 at 3:41 pm
  
  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 ↓
LOVE_MOSS_NOT July 31, 2012 at 6:37 pm

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 authorJuly 31, 2012 at 7:22 pm
  
  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 ↓
Bob September 4, 2012 at 5:14 am

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 ↓
Stuart January 7, 2013 at 2:11 am

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 ↓
1. Jens-Ingo Farley Post authorJanuary 10, 2013 at 10:42 pm
  
  Unless something has changed recently, there’s no way to submit bugs from outside Microsoft.
  
  Reply ↓
Pingback: Testování v reálných podmínkách | Jan Lender
Bear April 15, 2013 at 9:27 am

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

Reply ↓