Determine who/what reserved 5.5 GB of virtual memory in w3wp.exe

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

Virtual memory is just the address space allocated to the process. It has nothing to do with memory usage.

To the idiots downvoting me, please follow (and read) the links below:

1. Virtual Memory
2. Pushing the Limits of Windows: Virtual Memory
3. http://support.microsoft.com/kb/555223

Answer 2

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.

Answer 3

Reserved memory is very different from allocated memory. Reserving memory just allocates address space. It doesn't commit any physical pages.

This address space is likely allocated by IIS for its heap. It will only commit pages when needed.

If you really want to launch w3wp.exe from windbg, you probably need to launch it with valid command-line arguments. You can use Process Explorer to determine what the command line for the current w3wp.exe process is. For instance, on my server, mine was:

c:\windows\system32\inetsrv\w3wp.exe -a \.\pipe\iisipmeca56ca2-3a28-452a-9ad3-9e3da7b7c765 -t 20 -ap "DefaultAppPool"

I'm not sure what the UID in there specifies, but it looks it's probably generated on the fly by the W3SVC service (which is what launched w3wp.exe) to name the pipe specified there. So you should definitely look at your command line before launching w3wp from windbg.