I have VB.NET application in which one of the form has IE control in it, the application starts initially with memory size consumed around 9 MBs, but when IE form is launched, the memory consumed rises to 27 MB, and when that form is closed, the memory reduces merely by 3-4 MBs, so why memory allocated to IEFrame is not de-allocated automatically? is there any work around to solve this issue? if possible, launching the form as a separate process would be helpful.
-
2It's called **garbage collection**. It's *not supposed* to deallocate the memory immediately. Launching this as a separate process is not going to fix anything. I feel like I link to this a lot recently, but [I've already discussed your issue at length here](http://stackoverflow.com/questions/5191897/how-to-release-the-occupied-memory/5192350#5192350). – Cody Gray - on strike Mar 28 '11 at 06:42
-
@Cody Gray: Thanks for great in-depth information over Garbage Collection, as I was just aware of the overview of what Garbage Collection is for. – Kushal Mar 28 '11 at 07:09
3 Answers
If you make sure to dispose the form properly, the garbage collector should free up that memory eventually. Running the IE control in a separate process should not be necessary. However, if you are using IE 7, you might want to read this question about memory leaks.

- 1
- 1

- 1,794
- 1
- 13
- 21
-
-
There are two conditions when a form is not disposed on Close: when (1) it is part of a multiple-document interface (MDI) application, and the form is not visible; and (2) you have displayed the form using ShowDialog. In these cases you must call Dispose on the form manually. – Nils Magne Lunde Mar 28 '11 at 06:14
-
Okay, I've called form using ShowDialog, and called its `Dispose` method manually in parent form's focus as the child was launched modally, but still memory consumption persists. – Kushal Mar 28 '11 at 06:23
-
1If your system is not running low on memory, it might take a while before the GC frees up the memory. The memory consumption should not have any impact on application performance. – Nils Magne Lunde Mar 28 '11 at 06:28
-
Ya application performance is not impacted anyway, so better I let GC take care of memory (since the memory consumption is ranged between 8 MB to 30 MB during entire life-cycle of my application), after reading @Cody Gray's explanation, as I was monitoring memory usage with Task Manager. – Kushal Mar 28 '11 at 07:18
Why not just put that form in a separate application if this is an issue? There are plenty of ways you can pass whatever data between the two apps.

- 65,341
- 71
- 269
- 466
-
I guess, having separate application for just the form that has IE control would make application's installation cumbersome also, I'll have to make sure that form I'm relying on actually exists, which is an external factor. – Kushal Mar 28 '11 at 05:42
-
Why would the installation be cumbersome? All the .NET libs would already be installed. It's just another EXE copied to the same directory. There may be other tricks that might help, but if you really want to run something in a separate process, that seems the easiest way to me. – Jonathan Wood Mar 28 '11 at 05:57
-
If the separate application is also written in a .NET language, it will have the same "problem". Garbage collection won't recollect unused memory immediately. That's by design. Splitting this into two separate applications just introduces unnecessary complexity, both at development and installation time. – Cody Gray - on strike Mar 28 '11 at 06:46
The still allocated memory might not be an issue at all. If you have sufficient available memory in the computer the .NET Garbage Collector will not run to clean up. Only when you need the memory the GC will kick in.
If you want to make sure it is a leak you could do the following:
- Make sure you have no references to the form in any way.
- Call GC.Collect()
- See if the memory is still claimed
Do not put the GC.Collect() in the final build; it's just to make sure you are not hunting ghosts.

- 50,210
- 11
- 84
- 115