locked
The Method or operation not implemented RRS feed

  • Question

  • Hi,

    We have COM+ component running on the cluster ( 2 servers are there in the cluster).

    Proxy of the COM+ component has been installed on the webservers. Recently we have been getting this exception on the webserver.

    An unhandled exception is thrown by COM+ component.


    ExceptionType: System.NotImplementedException

    TargetSite: Void ThrowExceptionForHRInternal(Int32, IntPtr) Source: mscorlib

    Message: The method or operation is not implemented.

    StackTrace:

    Server stack trace:

       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

       at System.EnterpriseServices.Thunk.ContextThunk.GetTransactionProxyOrTransaction(Object& ppTx, TxInfo pTxInfo)

       at System.EnterpriseServices.ContextUtil.get_SystemTransaction()

       at System.Transactions.Transaction.JitSafeGetContextTransaction(ContextData contextData)

       at System.Transactions.Transaction.FastGetTransaction(TransactionScope currentScope, ContextData contextData, Transaction& contextTransaction)

       at System.Transactions.TransactionScope.CommonInitialize()

       at System.Transactions.TransactionScope.NeedToCreateTransaction(TransactionScopeOption scopeOption)

       at System.Transactions.TransactionScope..ctor(TransactionScopeOption scopeOption)

       at System.Transactions.TransactionScope..ctor()

       at BusinessObjects.LicenseControlManager.CreateUserLicense(String groupID) //  Call  is geting marshalled successfully to COM+ component

       at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)

       at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)

       at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

     

    Exception rethrown at [0]:

       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

       at BusinessObjects.LicenseControlManager.CreateEndUserLicense(String groupID)

       at BusinessObjects.B0.A(Member A_0, MemberProfile A_1, Boolean A_2) // Webserver calling  COM+ proxy



    By looking at the call stack, creation of new object of TransactionScope is failing. Exception doesnt provide any information about the Method which is not implemented. And, from the call stack it looks that it is coming from system library.


    We have also checked the eventvwr logs but no clue what so over.


    Could anyone provide what should we do to track down the problem? Is it possible this method (which is not implemented) is a custom method not system?



    -Sumit


    Saturday, May 10, 2008 7:16 PM

Answers

  • This is a tricky one to figure out without further information. At the point of failure, the infrastructure calls into the native OS code for some transaction-related work. There are a number of methods called and it is not possible to determine from the call stack which one returned the error.

     

    What happens underneath is that there are multiple transaction implementations that could be invoked. Some of them do not support all operations. If you hit one of them then you would get that error.

     

    You mentioned that this started to fail recently. I would investigate what changed to trigger the failure. Something you did caused the system to pick a different transaction implementation, one that does not implement some operation. If you can isolate the change that triggered the failure we can figure out what failed. If you are familiar with COM debugging you may also be able to determine the failed method in a debugger.

     

    Wednesday, May 14, 2008 8:43 PM

All replies

  • This is a tricky one to figure out without further information. At the point of failure, the infrastructure calls into the native OS code for some transaction-related work. There are a number of methods called and it is not possible to determine from the call stack which one returned the error.

     

    What happens underneath is that there are multiple transaction implementations that could be invoked. Some of them do not support all operations. If you hit one of them then you would get that error.

     

    You mentioned that this started to fail recently. I would investigate what changed to trigger the failure. Something you did caused the system to pick a different transaction implementation, one that does not implement some operation. If you can isolate the change that triggered the failure we can figure out what failed. If you are familiar with COM debugging you may also be able to determine the failed method in a debugger.

     

    Wednesday, May 14, 2008 8:43 PM
  • I know that it is a bit lat for answering this, but we recenlty come up with the same problem in a similar situation.

    The problem was that the Local DTCs weren't allowing Network Transactions, so the transaction couldn't be propagated from the Webserver machine, where it initiated, to the COM+ server.

    Enabling Network transactions was enough.


    I have replied as this is the only result you find googling the exception, and could be of use to someone else in the future.
    Monday, July 9, 2012 2:29 PM
  • Definitively its a problem with the MSDTC. One of our clients was getting a similar error and it was because they cloned wrongly the Application Server and the Web Server so they were sharing the MSDTC SID. This was causing the transactions to be aborted as soon as they were tried to be propagated to the application server.

    In our clients case if you restarted teh MSDTC service you get the following error which is pretty clear in the problem and solution:

    The local MS DTC detected that the MS DTC on GBLONTAS65 has the same unique identity as the local MS DTC. This means that the two MS DTC will not be able to communicate with each other. This problem typically occurs if one of the systems were cloned using unsupported cloning tools. MS DTC requires that the systems be cloned using supported cloning tools such as SYSPREP. Running 'msdtc -uninstall' and then 'msdtc -install' from the command prompt will fix the problem. Note: Running 'msdtc -uninstall' will result in the system losing all MS DTC configuration information.

    The following URLs could be of help to diagnose the problem if you ever have it:

    Check MSDTC traces:

    http://blogs.msdn.com/b/distributedservices/archive/2009/02/07/the-hidden-tool-msdtc-transaction-tracing.aspx

    MSDTC troubleshooting:

    http://msdn.microsoft.com/en-us/library/aa561924%28BTS.10%29.aspx


    Juan Casanova

    Friday, July 13, 2012 8:22 AM