Server info: Windows 2003 (IIS6) w/ 2GB RAM.

I have been getting  Exception of type 'System.OutOfMemoryException' was thrown.  very often with my asp.net website and the only way to recover is to manually recycle the application pool in IIS.

Looking into the issue, I see that IIS has a limit of about 800MB which is when you will start seeing OOM. Almost every topic on the subject deals with this 800MB issue. That isn't the issue for me. I am getting the OOM error when w3wp.exe is using less than 100MB of memory.

Is there anything else that could be causing this issue?

What sort of data/variables are you storing in Session and Application State?

Have you confirmed that the web.config on your Production system is not set to debug mode? e.g. has this line? <compilation debug="false"/>

If you are truly only using 100 of 800 mb and getting OOM exceptions, it is possible that you are experiencing severe fragmentation in your memory space. This can be cause by numerous things, the most common is running in debug mode. Another cause for fragmentation is loading numerous assemblies or generating numerous XSL templates.

With OOM exceptions those are where I start. What sort of service does your site provide? Consider trying some of the things described in the posts under Resources in this article.

We use several session variables but do not use application state. The session variable are mostly short string (less than 10 char) or Boolean values.

I think I have narrowed down the cause to an unmanaged dll (which is used for calling our address verification software). Running an address check several times in a row will always cause an OOM exception. This server is not live yet, so we had left the debug settings enabled. Setting <compilation debug="false"/> did not seem to have an effect, but setting <trace enabled="false" /> did seem to stop the error for now.

Another thing that did seem to work was calling GC.Collect() after each time an address was verified. I know this isn't a good practice, but can any harm come from doing this? Also, if running garbage collector can correct the issue, could it still be the unmanaged code causing it? (I thought GC only cleaned CLR memory, and that unmanaged code ran outside the CLR).

Thank you for your help. I will mark your post as an answer after my second question is cleared up (or if no one replies) since you pushed me in the right direction.

Honestly my experience with memory management and GC.Collect is limited.

Disclaimer made, my thoughts; GC.Collect() is more of a kludge/workaround, and can trigger some serious drawbacks. Calling the method forces the garbagecollector to run inside the same thread as your application, so if there is a large amount of garbage to collect you could experience delays/lag.

If the unmanaged library is being reloaded for each address verification (or each instance of verification) then it is possible that it is not being released properlly. If you describe how you are loading/using the address verfication library I'll try to help. And hopefully someone with more experience in memory management and garbage collection will jump in. I believe the common suggestion (when possible) is to create a managed library wrapper for the unmanaged code so it can be released easily.

I sincerely hope someone else will post you a more knowledgable answer :)

 I suggest that you run FXCOP on your web site (once you locate it in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files) or better still convert the web site to a Web Application.

FXCOP might just locate the cause of your problem. (It will also detect a lot of minor issues - these need to be fixed in orider to get the number of warnings below 200, otherwise you will not see all the warning messages.

 After running IIS Debug Diagnostics I found that my memory was 96% fragmented (not good). The memory leak rule found over 6,000 allocations for the address verification dll that I was suspicious of. Obviously something is not being unloaded correctly. I am now in contact with the software vendors to see if they can help resolve this issue. Thanks for the help.

FxCop would probably be a good idea regardless. I do usually try to run StyleCop, but have not gotten around to looking up the dll to run against FxCop.

Brad Engels:

FxCop would probably be a good idea regardless.

Running DFXCOP is easiest, if you use Web Application instead of Web Site

This out of memory issues seems very interesting. Could you please provide us the complete details once your issue is resolved.

Please provide the intial problem you faced and the resolution steps/methods you adopted. Thanks in advance