Altova Mailing List Archives

A Pathological Memory Allocation Behavior of MSXML4

From: "John Saunders [MVP]" <john.saunders at>
Date: 12/10/2007 7:54:00 PM

I don't know if this is the best place to ask this question; if anyone has 
an idea of another place I should ask, then please let me know.

At a customer site, we're seeing the virtual memory size of our COM+ 
application grow until it exceeds the maximum virtual memory a process can 
have. When we look at the dumps in windbg, it looks like MSXML is the 
culprit. There is a distinctive pattern of heap usage. An attempt to 
reproduce the problem in a development environment has not (yet) reproduced 
the out-of-virtual-memory problem, but _has_ reproduced the distinctive 
pattern of heap usage.

The heap usage pattern is that several heaps consist of a few "normal" heap 
segments, followed by a number of segments with only a single page 
committed. Each of these one-page-committed segments within a given heap has 
twice the reserved size as the one before it, yet has only a single page 
committed. Obviously, if this keeps up, virtual memory will eventually be 
full of one-page heap segments. In fact, this is what happens at our 
customer site.

We are using the normal, rental-threaded model with MSXML 4. We are using 
the DOM, with no SAX at all, and no XSL or XSD. I don't know if there's any 
XPATH, but there can't be much of it. My test program uses many threads to 
call our COM+ application, which in turn performs MSXML calls.

I've begun doing some memory allocation profiling with the AQTime 5 tool 
from Automated QA. It shows that all of the allocated segments with the 
committed vs. reserved discrepancy were allocated by a call to MSXML. These 
calls range from CreateInstance to setAttribute. I even saw one loadXml 

We're in the process of narrowing this down. My test program now calls only 
one of our COM+ methods, which performs mostly XML work. I'll be working on 
a narrower test that only does specific MSXML calls. In the meantime, I was 
hoping that this pattern of memory allocation is familiar to someone.

Thanks for any help or suggestions,

John Saunders | MVP - Windows Server System - Connected System Developer


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.