Re: 2.0 conversion : w3wp.exe using GOBS of memory

Chris wrote:
> I have an ASP.NET v1.1 web app that was running perfectly for a long
> time. I recently used the new "Web Application Project" type to convert my
> v1.1 application to v2.0
> Everything went smoothly with the migration, I made NO changes to the
> code and was able to deploy the project.
> I installed on a few production clients for BETA testing.
>
> The problem I am finding with 1 client in particular is a steady
> increase in memory usage for the w3wp.exe process.
> It grows over the course of a day [reaches over 300MB] and eventually
> the application crashes with errors such as:
> System.OutOfMemoryException: Creating an instance of the COM
> component with CLSID
>
> I searched the web and found that usually the answer is "you must
> have an infinite loop or some other memory leak",
> but again, I did not change any code between v1.1 and v2.0.
>

Chris,

The best thing to do in a case like this is use the GcFailFastOnOOM Registry
key with a value of 2 and attach a debugger such as Windbg. This will cause
a break in the debugger when the OOM occurs and you can see what's really
going on.

820745 Failfast occurs when you experience an "out of memory" condition
http://support.microsoft.com/default.aspx?scid=kb;EN-US;820745

Now for the problem. The only managed debugger extension you have access to
(SOS) is not compatible with the 2.0 Framework. Therefore, you're going to
have to get someone internal to Microsoft look at this for you. My
recommendation is that you open a case with Microsoft PSS. They can get
someone from my team to analyze a user-mode dump of the process and help
determine why you are seeing this OOM.

I will tell you that an infinite loop is almost never the cause of an OOM.
If an infinite loop is pushing something onto the stack, you'll see a stack
overflow long before you see an OOM. If it's not pushing anything onto the
stack, it will just spin forever. As for a memory leak, yes, that can cause
an OOM, but it's also quite possible to see an OOM condition in a low-memory
situation due to fragmentation, etc.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.



.

Relevant Pages

  • Re: xmalloc
    ... OOM (out-of-memory) condition. ... The 'static solution' may cause a 'stack' overflow. ...
    (comp.lang.c)
  • Re: Andrea VM changes
    ... >> And I don't see how you can avoid oom killing to ever happen if the apps ... >> recurse on the stack and growsdown some hundred megs. ... eventually fallback to sigkill. ...
    (Linux-Kernel)
  • Re: malfunctioning applications under limited stack size
    ... stack size is limited to anything fewer then exactly 2 GB ... ... Look in /var/log/messages for signs of the OutOfMemory (oom) killer. ...
    (comp.os.linux.misc)
  • Re: Andrea VM changes
    ... > And I don't see how you can avoid oom killing to ever happen if the apps ... > recurse on the stack and growsdown some hundred megs. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)