Tools for Detecting Memory Leaks

Hi everyone,

As many web devs know, it’s relatively easy to build a site which results in memory leaks when viewed in Internet Explorer. IE team members have written MSDN articles on leak patterns, and other sites have posted articles with varying tone, depending on the author’s frustration with the problem.

These memory leaks often occur as a result of circular references between Jscript objects and objects within IE’s DOM (document object model). Since the Jscript engine and IE have independent memory management schemes, each side can’t see the entire cycle of these circular references.

Internet Explorer 7 improved the situation by releasing all references to Jscript objects attached to the DOM tree when IE navigates away from that page. This allows the Jscript engine to then garbage collect those Jscript objects and recover that memory. We’ve also made the same changes in IE6 on Windows XP SP2 (shipped originally with the June Update). However, as some web developers have pointed out, those changes don’t solve the problem entirely. IE still leaves behind anything not attached to the tree when we tear down the markup. In addition, sites that users keep open for extended periods of time, such as Web-based mail, can still cause IE’s memory usage to continually grow if the site doesn’t take care to avoid the leak patterns.

So no, it’s not perfect, but we’re also continuing to invest in improvements for future versions of IE.

In the meantime, tools and best practices can help web developers find and remove leaks today.

Drip and sIEve (joint SourceFourge site) are two such tools. Many of you may already be familiar with them, but a little extra visibility never hurts. Both applications host Trident – IE’s rendering engine – and add detection of memory leak patterns. They let you track memory and DOM usage while using a site and then detect any leaks when you navigate away from that page. Drip is an open source project under the BSD license. Based on Drip, sIEve improves the usability in a few ways including non-modal dialogs and a real-time graph of DOM usage instead of memory usage. If you have questions/comments about the tools themselves, try the documentation, forum, or mailing list. And if you’re interested in taking a more active role in the project, contact Matthias Miller through the forum or mailing list.

Those tools will you help find the leaks, and here are a few articles that provide more information about removing them, or better yet, avoiding them in the first place:


John Hrvatin
Program Manager
Internet Explorer

Comments (25)
  1. Frank says:

    Any status on the public bug tracking?!

  2. John says:

    Tried the Firefox 3 beta yet? When will there be a beta for IE8?

  3. n-blue says:

    Fx 3 beta 2 still have memory problem, worse than IE7.


    Thanks for the detial but as Frank said we may need bug tracking (may be on connect) to report the bug or track on situation of reported bug. I think it not bad idea.

    Btw, people want to know something about what going on with IE8. For the promised of 12-18 month from the begining we should have some things around here.

  4. Un-blue says:

    n-blue, there is no Firefox 3 beta 2 yet so I doubt that it true.

    At least Mozilla is releasing something after a year. Hello IE?

  5. deathshadow says:

    >> Fx 3 beta 2 still have memory

    >> problem, worse than IE7.

    Hell, let’s be honest here, FF2 ‘stable’ still has memory leaks that makes IE7 look good.

  6. Vasil Dinkov says:

    I’ve been aware of Drip from quite some time and it is very useful! But I didn’t know about sIEve and it seems even nicer..

    So thanks very much!

    PS: However, please please try to fix these leaks in IE8!

  7. Harvey J. says:

    Thanks for the tips on Sieve! It is much better than drip, which can make it quite difficult to detect where the leaks are occurring.

    I also with Frank n-Blue and Un-blue on the bug tracking.

    Seriously guys! Since you can’t meet the release cycle you guys promised you would, the least you can offer is a bug tracking system so we can see what is going on!

    In IE8, am I still going to have to write craptacular code like this?

    //only for IE

    var sendButton = document.createElement(‘<input  name="sendit"/>’);

    sendButton.setAttribute(‘type’, ‘button’);//can’t set it after you add it to the DOM!

    sendButton.setAttribute(‘value’, ‘Send It’);

    customXBAddDOMEventHandler(‘click’, mySendItHandler);

    var myFormObj = document.getElementsById(‘myForm’);


    For adding this 1 button to a page, I need to work around at least 5 separate IE bugs!

    Not laughing at the lack of bug tracking anymore.  It shows a complete lack of respect to your fellow developers using IE.

  8. Laurent says:

    Well, since the IE6 fix is only available for XPSP2, there is little point to the fix. make it win2K compliant or better, release IE7 for win2K and give up on IE6.

  9. Al Billings says:


    There will never be an IE7 for Win2K. This was discussed, oh, two years ago?

  10. pinto says:

    @Harvey, the IE team does not and need not respect web devs.  It’s a constituency problem: web devs aren’t downloading the software: end users are.  As long as the end users are coming in on IE, web devs will have to grin and bear it.  What would they gain from  pretending to like web developers (pretending harder than this blog, that is)?  Say option 1 is: "public bug tracking database, transparency on future releases and actual effort at bringing IE up to the level demonstrated by Firefox, Webkit and Opera"  Option 2 is: "throw minimal resources at the problem, stonewall on the PR front and hope that the net effect of most web devs telling their friends and family to stay off of IE is minimal (it is)."  Hard to say that MS hasn’t taken option 2.  False dichotomy?  Maybe, but you’d have a tough time convincing me.

    FWIW, I’d like to think that the IE team is doing the best they can with the official support they’re getting.  However, since there’s virtually no transparency or information sharing between MS and the community, who knows?  I don’t want to be hard on a fellow developer, but then again, anyone at MS knew the sort of company they were signing on with…

    Anyway, there was a lengthy debate when the IE7 betas started trickling out over whether this was a one-time "OMFG! Firefox is killing us" attempt at leapfrogging (technically – we all know the market-share situation), or whether MS actually intended to once again become competitive in the browser market.  The stonewalling on IE8 (gag order issued by the PR dept?) seems to be all we need to decide matter.

  11. ivan says:

    you are right pinto, looks like they are doing a #2.

  12. Shadoz says:

    Any roadmap for the release of IE8. Firefox already has an FF 3.0 alpha.

  13. Fduch says:

    Memory leaks? Wasn’t that problem solved with .Net and Garbage Collecor?  

    Oh!? IETeam doesn’t know about .Net? Well… I guess it was reseased after IETeam stopped working in 2002. Go check They have some info on it.

  14. anonymous says:

    With Firefox 3.0, there are a hell lot of new features, so I’m finally switching. Microsoft either doesn’t get browsers or its browser division is still stuck in the 90s and deliberately kills progress.

  15. Pinky says:

    I still feel that Memory leaks is something which is really taking down the popularity of IE.

  16. Seriously guys! Since you can’t meet the release cycle you guys promised you would, the least you can offer is a bug tracking system so we can see what is going on! :S

  17. fredck says:

    We at FCKeditor are constantly fighting against memory leak. We have already fixed several related issues, but we were still facing an expressive memory leak with IE7.

    With some intuition, we were able to reduce the problem to a simple test case, and we have sadly found a new memory leak issue *introduced* with IE7.

    Essentially, every call to window.createPopup() leaks 80Kb of memory. A test page can be found here:

    In the default FCKeditor interface, we use six IE’s popups for all floating panels (toolbar combos and context menu). On pages with several editor instances, the memory increasing is substantial.

    As far as we could understand it, there is no way to "cleanup" that leak. We strongly hope IE8 and even IE7 will have it fixed as there is no way to workaround it (I hope I’m wrong!).

    Suggestions? Comments?

  18. Tim Tripcony says:

    @fredck – You’ll probably get dozens of comments to this effect, but window.createPopup is so Web 1.0 anyway. The "new approach" is to use positioned divs with z-indexes to create the illusion of a new window, but everything still exists within the same window. This also prevents popup blockers from preventing users (at least initially, until they’ve told their browser to allow popups from the current site) from using the feature that would otherwise load in a separate window. Check out the way ExtJS handles this for an elegant example.

  19. Nathan Toone says:


    I’m sorry, but that’s not the point.  The point is that this is a *new* leak, introduced in IE7.

    And to tell the truth, I don’t care how "Web 1.0" something is – not every project has the money, time, or ability to upgrade legacy applications to use a different javascript toolkit.  Many older applications make use of window.createPopup(), and a leak in such a core function is absolutely unacceptable.

  20. fredck says:

    @Tim: I’m pasting here the response I gave to the same kind of comment at Ajaxian:

    window.createPopup() has nothing to do with the popups we are used to see, which are instead created with They behave instead much like a floating iframe, but have some special features (like floating outside the browser itself). Popup blockers don’t block them.

    We have made some tests to avoid using window.createPopup, using floating divs or iframes instead. Then, we have another IE bug to fight here, because the cursor caret used on editing will always blink over floating elements, making the editor buggy to the user eyes. Using window.createPopup instead, we avoid this problem.

    Of course, we’ll be investigating it further in the future. Thanks for your comments.

  21. AlfonsoML says:

    We have done some further research (it turned out that I wasn’t suffering now the leak so we searched for the differences), and as explained in the problem is only present if the Anti-phising protection of IE7 isn’t disabled. That also explains why the problem isn’t visible in Drip or sIEve.

  22. IEBlog says:

    Over the past year, I’ve written about different tools to help web developers become more productive

  23. Over the past year, I’ve written about different tools to help web developers become more productive

  24. Today I was busy with ASP.NET and Ajax and I had some memory leaks in Internet Explorer 6. So I used

  25. &#160; &#160; 지난&#160; 1 년간, Internet Explorer 개발시에 웹 개발자의 생산성 향상을 도모하기 위한 다양한 도구 ( Web Development Tools

Comments are closed.

Skip to main content