A little history, read my sco posting about my previous headaches. This is happening with the same customer. They purchased a new server and have Red Hat Linux 6.0 Enterprise now instead of SCO. Universe 10.2 is working much faster and now fully supports connection pooling.

We developed a new website for this customer using .Net 2.0 and UniObjects.Net. We're finally ready to go live with it so we switch it live. The site runs great for a few then the w3wp.exe process cranks up in virtual memory usage, like over 300MB. Then the site freezes and crashes and eventually that process will die, and then a new one will be created and the sites will run fine until the VM usage is increased again. So we disabled the new site and kept on the old RedBack classic ASP site for now.

So, after spending 8 hours with Microsoft IIS Tech support, they determined it’s a UODOTNET.DLL issue and the way its finalizing memory (MS report below). Yeah, real fun. So I call IBM. After having to redial three times just to find the correct tech support (I may be slow, it’s been a long day) I get support. We enable trace logging for uniobjects, then run a load test tool and get it to crash, then sent it off to IBM. 

Response from Microsoft. Please, contact Microsoft directly for your issue if this doesn't resolve as each scenario is its own beast!

Start Microsoft Response ********************************************************

In short, as suspected, it’s the way the memory cleanup is implemented in IBM's UODOTNET component. They seem to have implemented the Finalizer (a queue data structure in .Net memory management terminology) in this component and when the Finalizer thread is trying to clean this up, it throws an error saying that it’s currently active. I am stating what we can do from this point on however, at the end I am also appending the raw dump analysis, just in case you are interested how we arrived at this:

Further course of action(s):
*******************************
I found this MSDN article http://msdn2.microsoft.com/en-us/library/system.object.finalize(VS.71).aspx which says "If Finalize or an override of Finalize throws an exception; the runtime ignores the exception, terminates that Finalize method, and continues the finalization process". So ideally it should not cause the worker process to crash but since it is ASP.Net 2.0 application we can try method 2 from following article
http://support.microsoft.com/kb/911816

So, we can try is to set the LegacyUnhandledExceptionPolicy to true in aspnet.config file and this way we might get rid of the crash. But irrespective of if we are able to avoid the crash this way, we would recommend you to pursue this with IBM because the root cause will still be there and will continue affecting the performance of the applications even if we avoid the crash somehow.

Detailed dump analysis:
--------------------------------------------------
This has nothing to do with OutOfMemory, those are just misleading exceptions. The crash is being generated from the finalizer thread which looks like the following

0:018> kL
ChildEBP RetAddr 
01def9fc 79f97065 kernel32!RaiseException+0x53
01defa5c 7a05b941 mscorwks!RaiseTheExceptionInternalOnly+0x226
01defa70 7a05b9b2 mscorwks!RaiseTheException+0x4c
01defa98 7a05b9ea mscorwks!RealCOMPlusThrowWorker+0x70
01defac4 7a05b9f5 mscorwks!RealCOMPlusThrow+0x37
01defad0 7a0e0701 mscorwks!RealCOMPlusThrow+0xa
01defc00 7a0e16e4 mscorwks!Thread::RaiseCrossContextException+0x63
01defcb4 79f3a09c mscorwks!Thread::DoADCallBack+0x25a
01defcd0 79f3581e mscorwks!ManagedThreadBase_DispatchInner+0x45
01defcd8 79f3ab82 mscorwks!ManagedThreadBase::FinalizerAppDomain+0x26
01defd34 79f350ea mscorwks!SVR::DoOneFinalization+0x143
01defdb0 79f3500e mscorwks!SVR::FinalizeAllObjects+0x54
01defdc8 79ecb4a4 mscorwks!SVR::GCHeap::FinalizerThreadWorker+0xe7
01defdd8 79ecb442 mscorwks!ManagedThreadBase_DispatchInner+0x4d
01defe6c 79ecb364 mscorwks!ManagedThreadBase_DispatchMiddle+0xb0
01defea8 79ed5e8b mscorwks!ManagedThreadBase_DispatchOuter+0x6d
01defed0 79ed5e56 mscorwks!ManagedThreadBase_NoADTransition+0x32
01defedc 79f6fd87 mscorwks!ManagedThreadBase::FinalizerBase+0xb
01deff14 79ecb00b mscorwks!SVR::GCHeap::FinalizerThreadStart+0xbb
01deffb8 77e6608b mscorwks!Thread::intermediateThreadProc+0x49

--and the exception stack looks like follows:

Exception object: 064a5dbc
Exception type: System.Exception
Message: [IBM U2][UODOTNET - UNICLIENT][ErrorCode=30114] An Execute is currently active on the server : Command Active
InnerException:
StackTrace (generated):
    SP       IP       Function
    01DEF924 022BA536 IBMU2.UODOTNET.UniPool.Free(IBMU2.UODOTNET.UniSession)
    01DEF95C 022BA10F IBMU2.UODOTNET.UniObjects.CloseSession(IBMU2.UODOTNET.UniSession)

This exception is leading to the crash.

The component that initiates it is as follows:

Loaded symbol image file: UODOTNET.DLL
    Image path: C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Filesroot3d1bd170aa024de5assemblydl348ad4183ee509929_d677c701UODOTNET.DLL
    Image name: UODOTNET.DLL
    Using CLR debugging support for all symbols
    Has CLR image header, track-debug-data flag not set
    Timestamp:        Fri Sep 08 16:00:36 2006 (4501D9F4)
    CheckSum:         00036D35
    ImageSize:        00038000
    File version:     2.1.1.7196
    Product version:  2.1.1.7196
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0
    CompanyName:      IBM
    ProductName:      UniObjects for .NET
    InternalName:     UODOTNET.dll
    OriginalFilename: UODOTNET.dll
    ProductVersion:   2.1.1.7196
    FileVersion:      2.1.1.7196
    FileDescription:  UniObjects for .NET
    LegalCopyright:   Copyright (C) IBM Corp.  1993, 2004
    LegalTrademarks:  IBM is a registered trade mark of International Business Machines Corporation.
    Comments:         .NET Interface to UniVerse and Unidata by IBM U2 Data Management Group

End Microsoft Response ***************************************************************

So I contact IBM universe support. Well, after two weeks of troubleshooting we found the issue. I use a TOXML option to convert a list to XML for handling in the script, a preferred method of IBM. So something like LIST FILE WITH A EQ B TOXML ELEMENTS or SELECT A, B FROM FILE WHERE A = B TOXML;. Either one returns an XML string which I then parse and load into a dataset. It works quite smoothly. The problem is that the TOXML has a limitation of about 1500 characters once it's converted. Some of my customer's products this application is handleing far exceeds that threshold, and as a result, would error the session and then the session would never close! In testing this through a telnet using Dynamic Connect, my session would just close, with no real helpful error. We reduced the size of the description of the products in question and we havent had an issue since. IBM told me that they are waiting on the next release of Universe for Linux until this can fix this issue. Yipee, I found a bug!

In closing, I know I've jumped on IBM a bit much regarding universe and uniobjects, and I've jumped on them even more than you've read here, but I do believe they have a potentially sweet database if they can get some of these oddities taken care of, and increase their user support for the product.