Troubleshooting MTS COM Errors in ASP on IIS: A Practical Guide

Table of Contents

Developing dynamic web applications with Active Server Pages (ASP) on Internet Information Services (IIS) often involves integrating with Component Object Model (COM) components, particularly those managed by Microsoft Transaction Server (MTS). While powerful for providing transaction management and reusability, this architecture can sometimes present unique challenges, particularly when it comes to component execution and identity management. One common and perplexing issue developers may encounter is a failure in server execution when an ASP page attempts to instantiate an MTS-managed COM component.

This guide provides a comprehensive breakdown of such errors, focusing on a specific, common cause related to MTS package identity. Understanding these legacy systems remains crucial for maintaining and troubleshooting existing applications, as many critical business systems still rely on this proven architecture. By delving into the symptoms, underlying causes, and practical resolutions, this article aims to equip you with the knowledge to diagnose and fix these intricate issues.

Understanding the Core Technologies¶

Before diving into the error itself, it’s essential to grasp the foundational technologies at play: COM, MTS, ASP, and IIS. Their synergistic operation is key to delivering robust web applications, and understanding their individual roles helps pinpoint where issues might arise.

Component Object Model (COM)¶

COM is a platform-independent, distributed, object-oriented system for creating binary software components that can interact with other components. It allows developers to build applications from pre-existing or custom components, fostering code reusability and modularity. In the context of ASP, COM components typically encapsulate business logic or data access functionalities, exposing interfaces that can be called from server-side scripts. Each COM component is uniquely identified by a Class ID (CLSID) and often has a human-readable Programmatic ID (ProgID).

Microsoft Transaction Server (MTS)¶

MTS, later integrated into COM+ in Windows 2000 and beyond, acts as a runtime environment for COM components. Its primary purpose is to provide an infrastructure for transaction processing, component pooling, and role-based security. Components are deployed within “packages” in MTS, which serve as logical containers for grouping related components and managing their execution environment. MTS abstracts away complex tasks like database transaction management, allowing developers to focus on business logic while ensuring data integrity. This framework was revolutionary for its time, simplifying distributed application development significantly.

Active Server Pages (ASP)¶

ASP is a server-side scripting environment that enables dynamic web content generation. ASP pages contain HTML, client-side scripts, and server-side scripts (typically VBScript or JScript) that execute on the web server before the page is sent to the client browser. ASP pages frequently interact with COM components to perform tasks like database queries, data manipulation, or integration with other backend systems. The Server.CreateObject method in ASP is the standard way to instantiate COM components, letting the web server manage the object’s lifecycle.

Internet Information Services (IIS)¶

IIS is Microsoft’s web server software, responsible for hosting websites and web applications, including those built with ASP. IIS handles incoming HTTP requests, processes ASP pages by executing their server-side scripts, and sends the resulting HTML back to the client. IIS works closely with MTS/COM+ by providing the environment where ASP scripts invoke COM components. The Application Pool identity in IIS also plays a role in the security context under which ASP pages execute, which can sometimes influence how COM components are instantiated.

Symptoms of Server Execution Failure¶

When an MTS COM component fails to be instantiated or executed from an ASP page, distinct error messages and event log entries provide crucial clues. Understanding these symptoms is the first step toward effective troubleshooting.

ASP Runtime Error: Server object error 'ASP 0177 : 80080005'¶

This is perhaps the most common and immediate symptom observed by end-users. When attempting to access an ASP page that creates a problematic MTS component, the browser displays:

Server object error 'ASP 0177 : 80080005'
Server.CreateObject Failed
/xxxx.asp, line xx
Server execution failed

Let’s break down this error:
* ASP 0177: This generic ASP error code indicates a problem with an object’s creation or a method call failing.
* 80080005: This is a COM-specific error code, also known as CO_E_SERVER_EXEC_FAILURE or E_ACCESSDENIED. It fundamentally means that the server process (in this case, the one hosting the MTS component) failed to start or respond, or that the client (the ASP page) lacked the necessary permissions to activate or access it. It’s a critical error implying a severe breakdown in the inter-process communication required for COM object creation. This code often points directly to permission issues or a failure in the environment where the component is meant to run.

Associated Event Log Entry¶

Complementing the browser error, the Windows Event Log (specifically, the Application or System log) will typically contain a more detailed entry that sheds light on the internal workings of the failure. A common entry for this scenario looks like:

EventID: 4134
Source: Transaction Server
Type: Error
Category: Executive
Failed on creation from object context: CoGetClassObject (ProgId: xxxx.xxxx) (CLSID: {B57CF3F7-66D3-496A-9D3B-55AE65A952FB}) (Interface: IClassFactory) (IID: {00000001-0000-0000-C000-000000000046}) (Microsoft Transaction Server Internals Information: File: d:\viper\src\runtime\context\ccontext.cpp, Line: 1285)
Data (words):
0000: 80080005

Analyzing this event log entry provides a deeper understanding:
* EventID: 4134, Source: Transaction Server: Clearly indicates the error originates within MTS (or COM+).
* Failed on creation from object context: Points to a failure during the instantiation phase of the COM object. The “object context” refers to the environment managed by MTS for the component.
* CoGetClassObject: This is a fundamental COM API function used to retrieve the class object for a specified CLSID, which is the first step in creating an instance of a COM component. Its failure suggests that the component’s factory could not be accessed or launched.
* (ProgId: xxxx.xxxx), (CLSID: {B57CF3F7-66D3-496A-9D3B-55AE65A952FB}): These identify the specific component that failed to create. The ProgID is the friendly name, and the CLSID is its unique identifier. This information is crucial for pinpointing the exact problematic component.
* (Interface: IClassFactory), (IID: {00000001-0000-0000-C000-000000000046}): IClassFactory is the standard COM interface implemented by every class object, responsible for creating instances of its class. The failure to access this interface directly indicates that the component’s creation mechanism is broken.
* Data (words): 80080005: This reiterates the same CO_E_SERVER_EXEC_FAILURE error code, confirming the permission or launch failure.

VBScript Runtime Error: ActiveX component can't create object: 'xxxx.xxxx'¶

If the component is created using the CreateObject method (which, unlike Server.CreateObject, doesn’t go through the ASP Server object directly and might be used in more complex scenarios or non-web applications), a different but related error might appear:

Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'xxxx.xxxx'
/ron/InvPerfStress.asp, line 14

• 800a01ad: This VBScript runtime error typically translates to “ActiveX component can’t create object.” While less specific than 80080005, it also points to an object creation failure. This often occurs when the component is not properly registered, when its dependencies are missing, or when the security context lacks the necessary permissions to instantiate it. In the context of MTS, it very strongly suggests an identity or permission issue preventing the component’s execution server from launching.

All these symptoms converge on a fundamental problem: the inability of the system to create an instance of the specified COM component within its designated execution environment.

The Root Cause: MTS Package Identity Set to ‘Interactive User’¶

The core reason behind these persistent errors, especially their intermittent nature, lies in how the Microsoft Transaction Server (or COM+) package identity is configured. Specifically, when an MTS Server Package’s identity is set to “Interactive User,” it means the components within that package will run under the security context of the user currently logged in to the server console.

Here’s why this is problematic for server-side applications:
* Dependency on Login Session: When the specified “Interactive User” logs off the server, their session terminates. Crucially, the process associated with the MTS package, which runs under that user’s identity, also terminates or becomes inaccessible.
* No Active User, No Component Execution: Without an active logged-in session for the “Interactive User,” the operating system cannot provide the necessary security context and environment for the MTS package to launch or maintain its components. Any subsequent attempts by ASP pages (or any other client) to create instances of components in that package will fail, resulting in the 80080005 error.
* Intermittent Nature: The problem appears “intermittent” because it only manifests when the “Interactive User” is logged off. If an administrator or the designated user is logged in, the application works fine, leading to confusion during troubleshooting.

Using Interactive User for server-side components is generally considered a poor practice for production environments due to its instability and reliance on a physical login. Server applications are designed to run autonomously and consistently, regardless of whether a user is logged into the console.

MTS Package Identity Options:¶

MTS (and COM+) offers different identity settings for packages, each with distinct implications for security and availability:

1. Interactive User (Default for new server packages): Components run under the identity of the user currently logged on to the server console. As discussed, this is highly problematic for continuous service.
2. Launching User: Components run under the identity of the user who initiates the component (e.g., the IIS anonymous user or the application pool identity). While better than Interactive User, this can still introduce complexities related to IIS application pool identity changes or specific client contexts.
3. Specific User: Components run under a predefined, static user account. This is the recommended setting for server applications. A dedicated service account (e.g., Domain\MTSUser or a local user) is created with the minimum necessary permissions. This ensures the component always runs under a consistent and controlled security context, independent of any interactive login.

The root cause of the error 80080005 in this specific scenario is the reliance on the Interactive User identity, which disappears upon user logoff, taking the MTS package’s execution context with it.

Steps to Reproduce the Behavior¶

Understanding how to reliably reproduce an issue is invaluable for confirming its cause and validating a fix. The following steps demonstrate how the “Interactive User” setting leads to the observed errors.

1. Create a New MTS Server Package:

   • Open Component Services (or Microsoft Management Console (MMC) and add the Component Services snap-in).
   • Navigate to Computers -> My Computer -> COM+ Applications (or Microsoft Transaction Server -> Transaction Server Explorer -> My Computer -> Packages for older MTS versions).
   • Right-click COM+ Applications (or Packages) and select New -> Application (or Package).
   • Proceed through the wizard, ensuring you select to create a “Server application” (or “Server Package”). When prompted for “Account” or “Package Identity,” accept the default option, which is typically “Interactive User” for new server packages. Provide a name for your package (e.g., MyProblematicPackage).
   • Explanation: This step sets up the problematic execution context for your components.

2. Add Your COM Component to This Package:

   • Within the newly created package, right-click Components and select New -> Component.
   • Follow the wizard to “Install new component(s).” Browse to and select your compiled COM component DLL (e.g., MyComponent.dll).
   • Explanation: The component is now part of the package configured to run under the interactive user’s context.

3. Create Your ASP Page:

   • Develop a simple ASP page that attempts to create an instance of your COM component using Server.CreateObject.
   • For example:
     

     <%@ Language=VBScript %>
     <%
       On Error Resume Next ' Enable error handling
     
       Dim myObject
       Set myObject = Server.CreateObject("MyComponent.MyClass")
     
       If Err.Number <> 0 Then
         Response.Write "<h1>Error creating component!</h1>"
         Response.Write "<p>ASP Error: " & Err.Description & "</p>"
         Response.Write "<p>COM Error Code: " & Hex(Err.Number) & "</p>"
         Response.Write "<p>Source: " & Err.Source & "</p>"
         ' For testing, you might want more detailed error logging in a real app
       Else
         ' Assuming your component has a method like GetMessage
         Response.Write "<h1>Component created successfully!</h1>"
         Response.Write "<p>Message from component: " & myObject.GetMessage() & "</p>"
         Set myObject = Nothing
       End If
     %>
     

   • Save this ASP page (e.g., testcomponent.asp) into a virtual directory on your IIS server where the MTS package is hosted.
   • Explanation: This page is the client that will trigger the component creation and expose the error.

4. Request the ASP Page While Logged On:

   • Ensure you are logged on to the server machine that hosts the MTS package (the “Interactive User”).
   • From a browser on a different computer (or even the same server, but mimic a remote request), navigate to the URL of your ASP page (e.g., http://yourserver/yourvirtualdir/testcomponent.asp).
   • Expected Result: The page should load successfully, indicating the component was created and executed without issues.
   • Explanation: With the interactive user logged in, the MTS package’s process is running correctly under that identity, allowing component creation.

5. Sign Out from the Server:

   • Log off the server machine where the MTS package is running.
   • Explanation: This action terminates the interactive user’s session, which is the crucial step in breaking the component’s execution environment.

6. Request the ASP Page Again:

   • From the browser on the different computer (or refresh the page requested in step 4), attempt to access the ASP page again.
   • Expected Result: The browser will display the error:
     

     Server object error 'ASP 0177 : 80080005'
     Server.CreateObject Failed
     /xxxx.asp, line xx
     Server execution failed
     

   • Simultaneously, an EventID: 4134 error with 80080005 will appear in the server’s Event Log.
   • Explanation: With no interactive user logged in, the MTS package’s execution context is gone, preventing the CoGetClassObject call from succeeding, thus causing the Server.CreateObject to fail.

7. Sign In and Change MTS Package Identity:

   • Log back into the server.
   • Open Component Services.
   • Navigate to your problematic package (MyProblematicPackage).
   • Right-click the package and select Properties.
   • Go to the Identity tab.
   • Change the setting from Interactive User to This user.
   • Click Set... and enter the credentials for a dedicated service account (a local user account on the server or a domain user account, e.g., .\MTSUser or mydomain\MTSUser) and its password. Ensure this user has “Log on as a batch job” and “Log on as a service” rights, though COM+ typically handles these for you during configuration. Click OK and then Apply.
   • Explanation: This step rectifies the core problem by assigning a persistent, independent identity to the MTS package.

8. Sign Out from the Server Again:

   • Log off the server machine.
   • Explanation: This verifies that the fix is effective even when no interactive user is logged in.

9. Request the ASP Page One Last Time:

   • From the browser on the different computer (or refresh the page), access the ASP page again.
   • Expected Result: The page should now work as expected, successfully creating and interacting with the COM component.
   • Explanation: The MTS package now runs under the specified user account, which remains active regardless of interactive logins, allowing component creation to succeed consistently.

This reproducible scenario vividly demonstrates the critical importance of proper identity management for MTS/COM+ applications running on server environments.

Resolution: Set the Package Identity to a Specific User¶

The solution to this intermittent server execution failure is straightforward: configure the MTS (or COM+) package to run under a “Specific User” account rather than the default “Interactive User” or “Launching User.” This ensures that the component’s runtime environment is stable and independent of any user login sessions.

Here’s a step-by-step guide on how to implement this resolution:

1. Create a Dedicated Service Account (if you don’t have one):

   • It is highly recommended to create a new, low-privilege user account specifically for running MTS/COM+ packages. This account should ideally be a domain account if your application spans multiple servers or a local user account on the server if it’s confined to a single machine.
   • Best Practices for the Service Account:
     • Strong, Non-Expiring Password: Set a complex password and configure it not to expire. Password expiration can lead to service outages.
     • Least Privilege: Grant this account only the necessary permissions. It should have permissions to access any databases, network shares, or other resources that your COM components interact with. Avoid making it an administrator unless absolutely necessary.
     • Logon Rights: Ensure the account has “Log on as a batch job” and “Log on as a service” rights. Component Services usually handles this automatically when you assign the identity.

2. Open Component Services:

   • On the server hosting the MTS package, open the Component Services administrative tool. You can typically find it in Administrative Tools in the Start Menu, or by typing dcomcnfg into the Run dialog.

3. Navigate to the Problematic Package:

   • In the Component Services console tree, expand Computers -> My Computer -> COM+ Applications.
   • Locate and expand the COM+ application (package) that is experiencing the errors.

4. Access Package Properties:

   • Right-click on the problematic COM+ application (e.g., MyProblematicPackage) and select Properties.

5. Configure Identity:

   • In the application’s Properties dialog box, click on the Identity tab.
   • You will see three options: Interactive user, Launching user, and This user.
   • Select the This user radio button.

6. Specify the User Account:

   • Click the Set... button.
   • In the User field, enter the full username of the dedicated service account you created (e.g., mydomain\MTSUser or .\MTSUser for a local user).
   • Enter the account’s password in both the Password and Confirm password fields.
   • Click OK to close the Set Account dialog.

7. Apply Changes:

   • Click Apply and then OK on the application’s Properties dialog box.

8. Restart the COM+ Application:

   • To ensure the changes take effect, it’s a good practice to restart the COM+ application. Right-click the COM+ application in the Component Services console and select Shut down (if it’s running), then Start.

Once these steps are completed, the MTS package and its contained components will consistently run under the specified user account’s security context. This eliminates the dependency on an interactive user being logged in, resolving the intermittent 80080005 errors and ensuring the stability and availability of your ASP application.

Status: By Design¶

This behavior, where COM+ applications configured for “Interactive User” fail when no user is logged in, is by design. It’s not a bug but a consequence of how Windows manages user sessions and process identities. The “Interactive User” setting is primarily intended for development and debugging purposes where a developer is actively logged into the server. For production environments, especially those hosting server-side applications like web servers, the “Specific User” identity is the correct and recommended configuration to ensure continuous availability and proper security isolation. Understanding this design choice is crucial for deploying robust and reliable COM+ applications.

Beyond Identity: Other Troubleshooting Considerations¶

While package identity is the direct cause of the error discussed, other factors can lead to similar COM component creation failures. For comprehensive troubleshooting, it’s beneficial to be aware of these.

Component Registration¶

A common reason for “ActiveX component can’t create object” (error 800a01ad) is that the COM component (its DLL) is not properly registered on the server. Without registration, the system cannot map the ProgID or CLSID to the actual DLL file, preventing its creation.

• Check Registration: Use regsvr32.exe YourComponent.dll from an elevated command prompt to register the component. If it’s a 64-bit component, ensure you’re using the correct regsvr32 from C:\Windows\System32. For 32-bit components on a 64-bit OS, use C:\Windows\SysWOW64\regsvr32.exe.
• Dependencies: Ensure all dependent DLLs or runtime libraries (e.g., Visual C++ Redistributables) required by your COM component are also present on the server.

DCOM Permissions¶

For out-of-process COM components (components running in their own separate process, which MTS/COM+ often facilitates), Distributed COM (DCOM) permissions can restrict launch and activation. While MTS/COM+ typically manages these, explicit DCOM settings can override or interfere.

• DCOMCNFG: Open dcomcnfg (Component Services). Navigate to Computers -> My Computer -> DCOM Config.
• Locate your component’s CLSID (if it appears directly under DCOM Config, sometimes MTS components are managed internally).
• Right-click and select Properties. Go to the Security tab.
• Check Launch and Activation Permissions and Access Permissions. Ensure the identity account configured for your MTS package, or the IIS application pool identity, has the necessary Local Launch, Remote Launch, Local Activation, Remote Activation, Local Access, and Remote Access permissions.

IIS Application Pool Identity¶

While the MTS package identity controls the COM component’s process, the IIS Application Pool identity controls the ASP page’s process. The ASP page, running under its Application Pool identity, must have sufficient permissions to call the MTS-managed component.

• Interaction: If the IIS Application Pool identity differs from the MTS package identity, ensure the Application Pool identity has permissions to access and launch DCOM applications.
• IIS Manager: Open IIS Manager. Navigate to Application Pools. Right-click on the application pool associated with your ASP application and select Advanced Settings.... Check the Identity setting. It’s often ApplicationPoolIdentity or a custom user. This identity needs permission to talk to the MTS COM+ application.

Event Viewer for Diagnostics¶

Always consult the Windows Event Log (Application and System logs) when troubleshooting COM/MTS errors. The detailed messages (like Event ID 4134 discussed earlier) provide context, error codes, and sometimes even file paths that are invaluable for pinpointing the exact failure point. Filtering by “Source” (e.g., “Transaction Server”, “DCOM”, “COM+”) or “Event ID” can quickly narrow down relevant entries.

Using Component Checker (for COM+ debugging)¶

For complex COM+ issues, the Component Checker tool (part of the Windows SDK, or sometimes found in older resource kits) can help diagnose problems with COM+ applications and their configurations. It can verify component registration, security settings, and other common issues.

Legacy Considerations and Modern Context¶

While MTS and classic ASP are considered legacy technologies, many critical business applications still rely on them. Understanding these systems is a valuable skill for any IT professional. The principles of identity management, process isolation, and inter-process communication learned from troubleshooting MTS/COM+ errors are highly transferable to more modern architectures like .NET services, Windows services, and even containerized applications.

The shift towards .NET and modern web frameworks (ASP.NET, Node.js, Python frameworks, etc.) has largely replaced the need for explicit COM+ components for typical business logic. However, integration with existing COM components or systems remains a requirement in many enterprise environments. The core lesson from this specific error – ensuring stable and independent process identities for server-side applications – remains universally applicable.

Conclusion¶

The “Server execution failed” error (ASP 0177 : 80080005) when calling MTS COM components from ASP on IIS, particularly its intermittent nature, can be a frustrating challenge. However, by systematically diagnosing the symptoms and understanding the critical role of MTS package identity, the resolution is often straightforward: changing the package identity from “Interactive User” to a “Specific User” account. This ensures that your COM components run consistently and reliably, independent of active user login sessions, thereby stabilizing your web application.

Always remember to check your Event Logs for detailed error information, and consider other factors like component registration and DCOM permissions if the identity change alone doesn’t resolve the issue. By applying these practical troubleshooting steps, you can maintain the stability and performance of your legacy ASP applications.

Have you encountered similar issues with MTS/COM+ or other legacy server applications? Share your experiences or additional troubleshooting tips in the comments below!