Question

On my machine (XP, 64) the ASP.net worker process (w3wp.exe) always launches with 5.5GB of Virtual Memory reserved. This happens regardless of the web application it’s hosting (it can be anything, even an empty web page in aspx).

This big old chunk of virtual memory is reserved at the moment the process starts, so this isn’t a gradual memory ‘leak’ of some sort.

Some snooping around with windbg shows that the memory is question is Private, Reserved and RegionUsageIsVAD, which indicates it might be the work of someone calling VirtualAlloc. It also shows that the memory in question is allocated/reserved in 4 big chunks of 1GB each and a several smaller ones (1/4GB each).

So I guess I need to figure out who’s calling VirtualAlloc and reserving all this memory. How do I do that?

Attaching a debugger to the process prior to the memory allocation is tricky, because w3wp.exe is a process launched by svchost.exe (that is, IIS/ASP.Net filter) and if I try to launch it myself in order to debug it it just closes down without all this profuse memory reservation. Also, the command line parameters are invalid if I resuse them (which makes sense because it’s a pipe created by the calling process).

I can attach windbg it to the process after the fact (which is how I found the memory regions in question), but I’m not sure it’s possible at that point to determine who allocated what.

Answer 1

David Wang answers this to a similar question:

[…] the ASP.Net performance developer tells me that:

• The Reserved virtual memory is nothing to worry about. You can view it as performance/caching prerequisite of the CLR. And heavy load testing shows that it is nothing to worry about.
• System.Windows.Forms – It’s not pulled in by empty hello world ASPX page. You can use Microsoft Debugging Tools and ‘sx e ld system.windows.forms’ to identify what is actually pulling it in at runtime. Or you can ildasm to find the dependency.
• mscorlib – make sure it is GAC’d and NGen’d properly.