I have a problem where the below code chunk causes handle leaks on some
machines. The leak APPEARS to be handles to the registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\Int ernet
Settings\ZoneMap

The below code runs on a timer running several times per second and
after about 15-30 minutes or so, it runs out of handles and crashes IE.

I found an article on msdn discussing how setting properties in this
way could cause memory leaks if the reference to the nodeValue in the
div isn't set to null before leaving the page (they suggest doing this
in an unload function though of course, that does not quite work here
since we aren't unloading... we're just constantly updating the data).


Instead, as you can see below, I've set the div's innerHTML to null
prior to resetting it.... to no avail. Any help would be much
appreciated.

--Mike

var currentId;
var responseXML;
var xmlDoc;

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
xmlhttp.open("POST", "<URL>" //where <URL> is the url that is
responding with xml data
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4)
{
responseXML = xmlhttp.responseText;
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.loadXML(responseXML);

for (i=0; i<xmlDoc.documentElement.attributes.length;
i++)
{
currentId =
xmlDoc.documentElement.attributes[i].nodeName;

document.getElementById(currentId).innerHTML =
null;
document.getElementById(currentId).innerHTML =
xmlDoc.documentElement.attributes[i].nodeValue; //Note:
Commenting out this line removes the handle leak.... but of course that
also prevents my data from updating.
}
delete xmlDoc;
xmlDoc = null;
responseXML = null;
}

xmlhttp.send(null);
delete xmlhttp;
xmlhttp = null;
}

> I have a problem where the below code chunk causes handle leaks on some
> machines. The leak APPEARS to be handles to the registry key:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Int ernet
> Settings\ZoneMap
>

Hi,
I'm just fighting exactly the same problem, but I don't think that this
is only related to XMLHTTP. I have latest WindowsXP (SP2+windowsupdate,
IE version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519). My IE seems to open
new handles each time I :

.. set src on SCRIPT element (2 handles)
.. set src on IFRAME element (2 handles)
.. set src on IMG elment (2 handles)
.. set innerHTML propery to some text (=no new elements) on DIV (or any
other visual element) (2 handles)

IE starts with 12 handles (having about:blank as homepage), then it
takes randomly another 2 or 4 handles each time I load the age/press
F5. This appears even if the page loaded is a 403 for instance. It's
not related to user auth scheme (I found this problem in out
application which is using NTML but it's the same even for anonymous
access). It's not related to membership of the server in zones - it
does the same when I put the server into "trusted" and when it's not
there. I've created small test page which allows you to test the
actions I mentioned (http://linda.cooper.cz/awe/test/ie/).

When the number of opened handles reaches 64k IE partly stops working,
if you had a server in "trusted" zone it starts to recognize it as
"internet" etc.

I'm going to test that on clean WindowsXP and then after each
servicepack/IE update to find the one which caused this problem but
this will take some time. Another clue might be that this behavior
can't be reproduced on Windows 2000 (SP4+windowsupdate).

Feel free to contact me if you need to clarify things/get additional
information.

With regards,
Martin

It's strange to reply to one's own post, but - the problem is caused by
hotfix 896688, the only trouble is that it fixes quite a holes in
security

It's strange to reply to one's own post, but - the problem is caused by
hotfix 896688, the only trouble is that it fixes quite a holes in
security

Martin Nedbal wrote:
> It's strange to reply to one's own post, but - the problem is caused by
> hotfix 896688, the only trouble is that it fixes quite a holes in
> security

Repying again to my own post - I talked to Microsoft guys here in Czech
Republic and according to them this bug is confirmed and hotfix is
planned to arrive in Feb 2006.