The CLR returns the excess memory to the OS whenever the OS asks the process
to trim it working set. However, this is not your problem. Each process in
Windows 32 bit can consume a maximum of 2GB of virtual memory space for data
and code, whenever you exceed this amount you will get an OOM exception. The
asp.net worker process however, restricts its virtual address space to a
(configurable) value which is much lower than this 2GB. By default, only 60%
of available system memory can ever be used as VAD space for the worker
process. So, for a system with 1GB of memory, that means that only 600MB can
be used by the asp.net worker process. If you want to allocate more than
this, you will have to increase the "memoryLimit" in your system.web config
file, but *much* better is to follow Mattias suggestion and use
XmlTextReader instead of XmlDocument.

Willy.

Just that very few applications do.  Here is a quote from MSDN:

"The HeapCreate function creates a private heap object from which the
calling process can allocate memory blocks by using the HeapAlloc function.
HeapCreate specifies both an initial size and a maximum size for the heap.
The initial size determines the number of committed, read/write pages
initially allocated for the heap. The maximum size determines the total
number of reserved pages. These pages create a contiguous block in the
virtual address space of a process into which the heap can grow. Additional
pages are automatically committed from this reserved space if requests by
HeapAlloc exceed the current size of committed pages, assuming that the
physical storage for it is available. Once the pages are committed, they are
not decommitted until the process is terminated or until the heap is
destroyed by calling the HeapDestroy function."

I don't know if the CLR uses HeapCreate or not, but almost all Windows
programs do.