The system memory usage and the handle counts increase more than you may expect when your application contains components that are derived from the System.EnterpriseServices.ServicedComponent class (312118)

SYMPTOMS

Note This article refers to the following Microsoft .NET Framework Class Library namespace:

System.EnterpriseServices.ServicedComponent

When you run an application that contains components that are derived from System.EnterpriseServices.ServicedComponent, the system memory usage may increase to more than 60 percent of the available memory. For example, if you run an ASPX application, the system memory usage may increase. Handle counts may also increase more than you expect. High CPU usage may be indicated in Windows Task Manager while the Req/Sec value remains at a reasonable level. If you examine managed heaps and unmanaged heaps, you find no evidence of memory leaks or of handle leaks. When Object.Finalize requests stop, the memory usage and the handle count eventually fall to more reasonable levels.

CAUSE

This problem may occur if the current version of the common language runtime is limited to one finalizer thread. If there are many worker threads manipulating managed finalizable objects, the finalizer thread can fall behind. In this scenario, the finalizer thread can fall behind especially if significant work occurs in the finalizer of each object. Serviced components may be vulnerable to this design issue because handles are held alive based on the COM+ object context. This is also true of other managed objects with complicated finalizers.

RESOLUTION

To resolve this problem, follow the common language runtime coding pattern by calling the Dispose method and the Dispose object when you finish with the managed objects that support IDisposable. Service component is a managed class that supports IDisposable.