>>What are oApp.Occurs() and oApp.At() ? Are you sure it is the UCase() rather than these which is causing the problem?
>
>Same as VFP Occurs() and VFP At().

I guessed what it does - wondered how it was implemented - but if the stack trace identifies UCase() as the culprit then it's irrelevant.

>The last line of the Stack trace gives this:
>
>at Microsoft.VisualBasic.Strings.UCase(String Value)
>
>>IAC, it would be more efficient to create upper case versions of the string for use in those functions rather than repeating the conversion each time.
>
>Will do.
>
>>Does using ToUpper() rather than the VisualBasic namespace UCase() also cause the OOM ?
>
>I never use that as all functions are mainly from the framework. So, if we change environment and do a framework for that, all the client code would remain as is for those functions in case ToUpper() wouldn't exist.

? String.ToUpper() is in the core System namespace. It's not going anywhere...

> But, at this point, it is difficult to try a few changes as it is only in the production that the problem started yesterday. That code as always worked well for a few years and still works well in our test servers.

Is the production server 64bit? Are you compiling for 64bit (or Any CPU) ? Do the dev servers have more RAM than the production server?

I wouldn't assume that UCase() itself is the problem - code leading up to the execution of that function might be responsible for eating into available memory.

Good link on troubleshooting : http://blogs.iis.net/webtopics/archive/2009/05/22/troubleshooting-system-outofmemoryexceptions-in-asp-net.aspx
Also look at using DebugDiag which can track memory allocation....