none
COM+ Instability causing processing terminate on Win 2003 SP2

    Question

  • Hi All,
    I'm pulling my hair out with this one. I have a .NET 2.0 application where some of the components are hosted in COM+ (Enterprise Services) and in some cases, calling the
    components can cause COM+ to fail.
    The following is logged in the event log:

    Event Type:    Error
    Event Source:    COM+
    Event Category:    (98)
    Event ID:    4689
    Date:        10/08/2007
    Time:        11:53:20
    User:        N/A
    Computer:    LGXSERVER1
    Description:
    The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. CTransactionMarshal::MarshalInterface

    Server Application ID: {C2F97EAF-47B3-446E-BB54-C5E76F5918CC}
    Server Application Instance ID:
    {5EDCD0E2-B3D6-4F8C-8083-0B7F29A33E67}
    Server Application Name: lgxEWorkflowEvents
    The serious nature of this error has caused the process to terminate.
    Error Code = 0x80030009 : Invalid pointer error.
    COM+ Services Internals Information:
    File: d:\nt\com\complus\src\comsvcs\txprop\txmar.cpp, Line: 198
    Comsvcs.dll file version: ENU 2001.12.4720.3959 shp


    This is on a Windows 2003 server running service pack 2.
    I get no such problems on a Windows XP system.

    Thanks in advance
    Mark
    Monday, August 13, 2007 2:13 PM

Answers

  • Hi - thankyou for responding.

    I've been trying for a couple of days now to come up with a surefire way of causing this problem so I can do just that. Unfortunately, it is intermittent, so we're still trying to understand the exact circumstances of when it occurs.
    I will continue trying, but all I can tell you at the moment is that the problem occurs when calling one COM+ component from another, when the first component has started a transaction using the System.Transactions classes.

    e.g.
    Code Snippet

    TransactionOptions txOpt = new TransactionOptions();
    txOpt.IsolationLevel = IsolationLevel.ReadCommitted;
    using (TransactionScope tx = new TransactionScope(TransactionScopeOption.Required, txOpt, EnterpriseServicesInteropOption.Full))
    {

    someDAC.UpdateState();


    SomeAgent extAgent = new SomeAgent();

    foreach(Item foo in itemList)

    {

        extAgent.DoSomething(foo.UniqueId);
    }

                
        tx.Complete();
    }


    So, we create a transaction via MSDTC update some objects state in the db, then
    loop calling another enterprise services component within the same transaction scope.
    The calling Enterprise services component has Transactions Disabled in the COM+ snapin (ie there is no automatic transaction support - everything is handled via TransactionScope as required). The "SomeAgent" component being called is somewhat legacy component that has been rebuilt against .Net2 and uses automatic transactions from COM+ with the transaction option set to "Required". This component makes various db insert and update calls and finishes by raising an event. The event being raised is a Loosely Coupled Event (LCE), whose event class is also registered within the COM+ environment.

    All components are run as Server components (ie run within the dllhost COM surrogate), all have object pooling and JITA support enabled, and are also therefore synchronised.

    I'm convinced the problem lies somewhere in the transaction support of COM+ - i.e. its having problems joining the transaction created by the first component. We have seen similar problems in the past on some XP machines where we had to disable promotable transactions (see http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1309835&SiteID=1), but this slightly different and we're unsure of the cause.

    Thanks
    Mark.
    Wednesday, August 15, 2007 9:11 AM

All replies

  • Hi MarkBennetts,

    To troubleshoot this issue, we really need the source code to reproduce the problem, so that we can investigate the issue in house. It is not necessary that you send out the complete source of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business logic from it.

    Thanks for your understanding!

    Wednesday, August 15, 2007 3:22 AM
  • Hi - thankyou for responding.

    I've been trying for a couple of days now to come up with a surefire way of causing this problem so I can do just that. Unfortunately, it is intermittent, so we're still trying to understand the exact circumstances of when it occurs.
    I will continue trying, but all I can tell you at the moment is that the problem occurs when calling one COM+ component from another, when the first component has started a transaction using the System.Transactions classes.

    e.g.
    Code Snippet

    TransactionOptions txOpt = new TransactionOptions();
    txOpt.IsolationLevel = IsolationLevel.ReadCommitted;
    using (TransactionScope tx = new TransactionScope(TransactionScopeOption.Required, txOpt, EnterpriseServicesInteropOption.Full))
    {

    someDAC.UpdateState();


    SomeAgent extAgent = new SomeAgent();

    foreach(Item foo in itemList)

    {

        extAgent.DoSomething(foo.UniqueId);
    }

                
        tx.Complete();
    }


    So, we create a transaction via MSDTC update some objects state in the db, then
    loop calling another enterprise services component within the same transaction scope.
    The calling Enterprise services component has Transactions Disabled in the COM+ snapin (ie there is no automatic transaction support - everything is handled via TransactionScope as required). The "SomeAgent" component being called is somewhat legacy component that has been rebuilt against .Net2 and uses automatic transactions from COM+ with the transaction option set to "Required". This component makes various db insert and update calls and finishes by raising an event. The event being raised is a Loosely Coupled Event (LCE), whose event class is also registered within the COM+ environment.

    All components are run as Server components (ie run within the dllhost COM surrogate), all have object pooling and JITA support enabled, and are also therefore synchronised.

    I'm convinced the problem lies somewhere in the transaction support of COM+ - i.e. its having problems joining the transaction created by the first component. We have seen similar problems in the past on some XP machines where we had to disable promotable transactions (see http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1309835&SiteID=1), but this slightly different and we're unsure of the cause.

    Thanks
    Mark.
    Wednesday, August 15, 2007 9:11 AM
  • Anyone got any ideas for this - its still causing us big issues on our production kit?

    Thanks
    Mark
    Thursday, October 18, 2007 4:04 PM
  • We are running a transactional COM+ application and get the COM+ surrogate error on all our servers after installing Win 2003 Server SP2. We can not replicate the error, it seems to occur randomly and the event log information is sparse to say the least:

     

    Event Type: Error
    Event Source: Application Error
    Event Category: (100)
    Event ID: 1000
    Date:  2007-10-29
    Time:  16:20:13
    User:  N/A
    Computer: CTMS-FE0
    Description:
    Faulting application dllhost.exe, version 5.2.3790.3959, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0004afb2.

     

    The "COM Surrogate encountered a problem and needed to close" dialouge that pops up also seem to affect system perfomance. When about 5 errors have occured and the dialouges have not been closed we start to get random data access errors. This is verry annoying as we now have to log on to the servers and clear the errors manually.

    Tuesday, October 30, 2007 8:29 AM
  • Hi all:

    Would really appreciate help on this one. We are having a very similar problem to this one on a Windows Server 2003 sp2 system except that we can produce the error consistently.

    When we perform a DTC transaction with TransactionScope EnterpriseServicesInteropOption.Full, the IIS app pool hangs. The interesting thing is that if the user is added to the "Power Users" or Administrators group, everything works correctly. So it looks like some permissions problem where the user does not have enough rights to complete the DTC transaction. I did some troubleshooting with ProcessMonitor but the volume of data it generates makes it hard for me to interpret. We are close to calling MS Premier Support to see if some Post -SP2 COM+ hotfix is needed.  Any clues would be helpful - thanks very much.


    Event Log entry:

    Event Type: Error
    Event Source: COM+
    Event Category: (98)
    Event ID: 4689
    Date:  4/23/2009
    Time:  5:01:11 PM
    User:  N/A
    Computer: TSTMOSSPC102
    Description:
    The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. CTransactionMarshal::MarshalInterface

    Process Name: w3wp.exe
    The serious nature of this error has caused the process to terminate.
    Error Code = 0x80030009 : Invalid pointer error.
    COM+ Services Internals Information:
    File: d:\nt\com\complus\src\comsvcs\txprop\txmar.cpp, Line: 198
    Comsvcs.dll file version: ENU 2001.12.4720.3959 shp

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Friday, April 24, 2009 3:17 PM
  • We are having this exact same problem, also since we upgraded to Win 2003 Server Sp2.

    We have tried various Pooling and Recycling settings in COM, disabling DEP, plus various code changes and logging in our code to try and track the problem but just cannot seem to find out what is causing it.

    We believe that something is happening in one of our COM Objects which Windows does not like, and so is killing the dllhost.exe that is running that instance of COM. The user making that call, plus any other users making a call to other COM objects in that package, gets a 'Remote Procedure Call Failed' error message.

    We then see the 'COM Surrogate' pop up on the COM server, along with the entries in the Event Log!

    Did you find a solution to your problem in the end?

    Monday, September 27, 2010 10:24 AM
  • Still no solution to this problem - just reared its ugly head again on our production system.

     

    Anyone else who had a similar problem manage to find a solution to this?

    Monday, August 01, 2011 9:11 AM