Hi,

Currently were moving all our IE hosted java controls over to .NET, we
have a two framed web page, the top frame contains a server client that
receives messages from a server stores various information and also
fires various events to which controls in the lower frame can register
for and act upon.

I've noticed a problem where by when the lower frame loads another web
page that the controls that were hosted in there are still active in
the background. I've registered for the HandleDestroyed event so I can
cut down on a lot of the problems by un-registering for the other
events etc. But the main problem is that it doesn't seem to free up
all the memory those controls were using.

Obviously this is a major concern as if they switch between various
different frames there is going to be a lot of memory being used
without reason.
So I'm just wondering whether there is anything that I need to do when
the handle is destroyed to make it clear up, ie tell the garbage
collector to do its business? What exactly is going off with the
controls hosted in IE's App Domain?

Any information would be greatly appreciated, this product won't be
fit to pass QA if it's eating memory due to .NET / Internet Explorer
not working as we assumed it should.
I spent a couple of minutes switching the bottom frame between
different controls... alarmingly it's increased my page file by over
300mb and creates 5 threads on the IExplore process each switch...
IExplore.exe now has over 400 threads...

Memory usage appears to drop gradually, but the PageFile is not slowly
dropping and neither is the number of threads being used...

How can I monitor what controls are sat in the background effectively
doing nothing and storing memory and have threads attached to them?

I have a feeling the issue may not be to do with .Net's Garbage
Collection but more likely to do with IE not destroying the controls
totally when switching the page in a frame whilst a .Net control is
still hosted in another frame?

Obviously I can't confirm this suspicion as I don't know how IE does
this... but adding 10mb to the Page File and 5 threads to the IExplore
process every time I switch the page in the frame doesn't sound great
to me... end users could have IE open all day and switch views many
many times, how many threads before IE dies? how much will the Page
File take before it causes problems? Will it clear itself? I can't
answer these questions...

Regards,
Kris Wragg

Hi,

Unfortunately I am not an IE expert but you could try following the steps
in the article below to see if the controls are rooted:
http://blogs.msdn.com/ricom/archive/...10/279612.aspx

Your questions:
how many threads before IE dies?
If this is 32 bit version of Windows you could probably get to around 1100
threads before seeing OOM's. 32 bit OS means 2 GB Virtual address space.
Each thread reserves a mb and commits 4k by default.
how much will the PageFile take before it causes problems?
Depends on how you have this configured. It's usually recommended to set
this to 1.5 times the amount of RAM you have on the machine. However the
OS shouldn't page unless RAM is unavailable.
Will it clear itself?
Ram + PageFile == Physical memory. So if all your processes have committed
more memory than you have RAM, memory will get swapped out to the page
file.

HTH,

Dan

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2002 Microsoft Corporation.
All rights reserved.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Please reply to the newsgroups only.