How to get around the memory leak in the .NET Webbrowser control?

Question

This is a widely-known, old issue with the .NET Webbrowser control.

Summary: Having the .NET webbrowser control Navigate to a page increases memory usage that is never freed.

Reproduce the memory leak: Add a WebBrowser control to a form. Use it to Navigate to whatever pages you'd like. about:blank works, scrolling down on Google Images until your usage is 100MB+ and then browsing elsewhere to notice barely any of that memory is freed is a more dramatic demonstration.

My current requirements for an application include running it for long periods of time, displaying a limited IE7 browser window. Running IE7 itself with some bastard setup of hooks, BHOs and group policies isn't desired either, although that's looking like the fallback at this time. Embedding a browser into a Windows Forms application is. Using a different browser base is not an available option for me. IE7 is required.

Previous threads and articles relating to this known memory leak:

• http://www.vbforums.com/showthread.php?t=644658
• How to Fix the Memory Leak in IE WebBrowser Control?
• Memory leak when using WPF WebBrowser control in multiple windows
• http://social.msdn.microsoft.com/Forums/en-US/ieextensiondevelopment/thread/88c21427-e765-46e8-833d-6021ef79e0c8/
• http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/8a2efea4-5e75-4e3d-856f-b09a4e215ede
• http://dotnetforum.net/topic/17400-appdomain-webbrowser-memory-leak/

Often-proposed fixes that DO NOT WORK:

• Going to different pages does not matter. about:blank triggers the leak. It does not require a page to have javascript, or any other extra technology.
• Using different versions of Internet Explorer does not matter. 7, 8, and 9 all exhibit the same symptoms, and as far as I've heard, all versions have the same memory leak in the control.
• Dispose()ing of the control does not help.
• Garbage Collecting does not help. (In fact, research I've done into this indicates the leak is in unmanaged COM code that the Webbrowswer control wraps.)
• Minimizing and setting process available memory to -1, -1(SetProcessWorkingSetSize() or simimlar.) only reduces physical memory usage, has no impact on virtual memory.
• Calling WebBrowser.Stop() is not a solution, and breaks functionality for using anything but static webpages, without doing more than just minimizing the leak slightly.
• Forcing a wait for a document to load completely before Navigating to another also doesn't help.
• Loading the control in a separate appDomain does not fix the issue. (I've not done this myself, but research shows others having no success with this route.)
• Using a different wrapper such as csexwb2 does not help, as this also suffers from the same issue.
• Clearing the Temporary Internet Files cache does nothing. The problem is in active memory, not on disk.

Memory is cleared when the entire application is closed and restarted.

I'm willing to write my own browser control in COM or Windows API directly, if that's a for-sure fix to the problem. Of course, I would prefer a less complicated fix; I'd rather avoid going down to lower levels to do things, because I don't want to be reinventing the wheel in terms of supported features of a browser. Letalone duplicating IE7 features and nonstandard behaviours in a roll-your-own style browser.

Help?

Answer 1

This leak appears to be a leak in unmanaged memory, so nothing you do in your process is going to reclaim that memory. From your post I can see that you've tried avoid the leak quite extensively and without success.

I would suggest a different approach if feasible. Create a separate application that uses web browser control and start it from your application. Use the method described here to embed newly created application within your own existing application. Communicate with that application using WCF or .NET remoting. Restart the child process from time to time to prevent it from taking to much memory.

This of course is quite complicated solution and the restart process could probably look ugly. You might maybe resort to restarting the whole browser application every time user navigates to another page.