Skip to content


August 10, 2009

The problem is eventual non-responsiveness of the website under load, a large number of request objects appearing, and eventual need for IIS reset because of COM Interoperability Issue.


ASP.Net is basically a MTA threaded model and when a COM object of MTA threaded model is called by a method then COM object executes in multiple thread. Here both objects are of the same threaded model, so the object doesn¬タルt have any deadlock or memory leaks. If the COM object is STA threaded model then the STA component cannot be accessed because ASP.Net being an MTA process thread model. This might cause some deadlock or memory leaks in the application.

Centridge-IPS application executes in MTA threaded model and a MTA COM object from ECPAppObject is executed in our application. This MTA COM object internally executes some STA COM objects. Suppose STA component object has to be maintained in a sharable apartment of a single thread in the page which is a MTA apartment model then STA component cannot be accessed.

Here the COM object is late bounded and information about the native COM component is known only after runtime. To create a late-bound server instance of a COM component, HttpServerUtility.CreateObject() method is used and the component’s programmatic identifier (ProgID) is passed to Server.CreateObject().

The COM component is instantiated depends largely on how the threading model of the native COM component is marked in the registry, as Free, Apartment, Neutral, or Both.

Components Marked Free:

When ASP.NET code calls a COM component that is marked as Free threading model, the component is instantiated on the same thread pool thread that the page started running on. The thread pool threads that process ASP.NET pages, such as input/output (I/O) completion port threads and worker threads, are initialized as multithreaded apartment (MTA) threads. Because the component is marked Free and the ASP.NET thread is default initialized as MTA, no thread switch is necessary and the performance penalty is marginal.
Components Marked Apartment:

When code calls a COM components are marked as Apartment threading model. The single-threaded apartment (STA) threading model is not compatible with the default threading model for the ASP.NET thread pool, which is MTA. As a result, calling a native COM component marked Apartment from an ASP.NET page results in a thread switch and COM cross-apartment marshalling.

If the COM component marked Apartment is not configured in COM+, the component will be instantiated on the Host STA thread of the Aspnet_wp.exe process. If the COM component marked Apartment is configured in COM+, a thread switch occurs to a COM+ STA worker thread from the MTA thread that the page started running on. In the unconfigured case, if the component marked Apartment makes a long running blocking call, so no new unconfigured components marked as Apartment threading model can be instantiated or perform work on that same thread. Under stress, this presents a severe bottleneck. To work around this issue, a new directive called ASPCompat was introduced to the System.Web.UI.Page object.


The ASPCompat attribute minimizes thread switching due to incompatible COM threading models. More specifically, if a COM component is marked Apartment, the ASPCompat = “true” directive on an ASP.NET page runs the component marked Apartment on one of the COM+ STA worker threads.

Assume that you are requesting a page called UnexpectedCompat.aspx that contains the directive ASPCompat =”true”. When the page is compiled, the page compiler checks to see if the page requires ASPCompat mode. Because this value is present, the page compiler modifies the generated page class to implement the IHttpAsyncHandler interface, adds methods to implement this interface, and modifies the page class constructor to reflect that ASPCompatMode will be used.

This IHttpAsyncHandler interface implements BeginProcessRequest and EndProcessRequest methods which begin and end the process request to perform in STA threaded mode.

If ASPCOMPAT mode is used (that is, the page with <%@ ASPCOMPAT=”true” %> directive), then those pages runs on an STA thread pool. However, Component Object Model (COM) components that are created at construction time are created before the request is scheduled to the single-threaded apartment (STA) thread pool and are therefore created from a multithreaded apartment (MTA) thread. In this scenario, you experience substantial performance degradation.

Most significantly, the same thread (host STA) executes all instances of apartment-threaded components that are created from MTA threads. This means that even though all users have a reference to their own instance of the COM component, all of the calls into these components are serialized to this one thread (only one call executes at a time).

Additionally, there is a smaller performance hit each time a call is made to the component from the Page events because of a thread switch. This is because the Page events are executed on a thread from the STA pool, but the COM component is still executed on the host STA (because the COM component was created from an MTA client). This thread switch also leads to other errors when using impersonation.

If ASPCOMPAT mode is used with STA components, only create COM components from a method or on the Page events (for example, Page_Load, Page_Init, and so on), and do not create these COM components at construction time.

By Murli Manohar J M, On 3/8/07 2:15 PM
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: