Hello Z,
I am working with a customer that is experiencing the following behavior:
*******************************************************************************************************************************************
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ObjectDisposedException
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean ByRef)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(System.Runtime.InteropServices.SafeHandle, Boolean ByRef)
at Microsoft.Win32.Win32Native.SetEvent(Microsoft.Win32.SafeHandles.SafeWaitHandle)
at System.Threading.EventWaitHandle.Set()
at Opc.Ua.Bindings.TcpAsyncOperation`1System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.InternalComplete(Boolean, System.Object)
at Opc.Ua.Bindings.TcpAsyncOperation`1System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.OnTimeout(System.Object)
at System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireNextTimers()
at System.Threading.TimerQueue.AppDomainTimerCallback(Int32)
*******************************************************************************************************************************************
and also :
*******************************************************************************************************************************************
OpcLabs.EasyOpc.UA.OperationModel.UAException: An OPC-UA operation failure with error code -1 (0xFFFFFFFF) occurred, originating from ''. The inner exception, of type 'OpcLabs.EasyOpc.UA.Engine.UAClientEngineException', contains details about the problem. ---> OpcLabs.EasyOpc.UA.Engine.UAClientEngineException: Cannot lock the OPC-UA client session because it is not available.
+ The client method called was 'ReadMultiple'.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.UA.EasyUAClient.CheckSuccess(OperationResult operationResult)
at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.ReadValue(IEasyUAClient client, UAReadArguments readArguments)
at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.ReadValue(IEasyUAClient client, UAEndpointDescriptor endpointDescriptor, UANodeDescriptor nodeDescriptor)
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.IsOpcOnline(EasyUAClient opc, String device) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 120
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.GetOpcForCall(String tag) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 147
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.ReadOpcTags(String server, String[] tags, String sender) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 0
*******************************************************************************************************************************************
The customer upgraded the quick OPC dlls from 5.50 to 5.54 as well as updating the server to TOP Server 6.6 from V5.21. Since he updated the Dlls he started to get the first exception (The process was terminated due to an unhandled exception) which if I recall correctly, this could possibly be an issue with the "Boxing". We suggested to him to disable the boxing using these instructions - kb.opclabs.com/How_to_disable_prerequisites_boxing - even though we were under the impression that his issue was fixed on version 5.54. but we wanted to see if this had any effect. Ever since he disabled the boxing, he has not seen the exception thrown again; however, the second exception is occurring 2 to 3 times in an hour pretty consistently.
This is only occurring on the production environment which has been updated to the same quick opc version. He has also updated the .NET Runtime to 4.6.2. He is running his service on Server 2016. Have you seen this behavior before? Do you jave any suggestions on what might be the issue? Thanks in advance.
I am working with a customer that is experiencing the following behavior:
*******************************************************************************************************************************************
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ObjectDisposedException
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean ByRef)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(System.Runtime.InteropServices.SafeHandle, Boolean ByRef)
at Microsoft.Win32.Win32Native.SetEvent(Microsoft.Win32.SafeHandles.SafeWaitHandle)
at System.Threading.EventWaitHandle.Set()
at Opc.Ua.Bindings.TcpAsyncOperation`1System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.InternalComplete(Boolean, System.Object)
at Opc.Ua.Bindings.TcpAsyncOperation`1System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.OnTimeout(System.Object)
at System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireNextTimers()
at System.Threading.TimerQueue.AppDomainTimerCallback(Int32)
*******************************************************************************************************************************************
and also :
*******************************************************************************************************************************************
OpcLabs.EasyOpc.UA.OperationModel.UAException: An OPC-UA operation failure with error code -1 (0xFFFFFFFF) occurred, originating from ''. The inner exception, of type 'OpcLabs.EasyOpc.UA.Engine.UAClientEngineException', contains details about the problem. ---> OpcLabs.EasyOpc.UA.Engine.UAClientEngineException: Cannot lock the OPC-UA client session because it is not available.
+ The client method called was 'ReadMultiple'.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.UA.EasyUAClient.CheckSuccess(OperationResult operationResult)
at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.ReadValue(IEasyUAClient client, UAReadArguments readArguments)
at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.ReadValue(IEasyUAClient client, UAEndpointDescriptor endpointDescriptor, UANodeDescriptor nodeDescriptor)
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.IsOpcOnline(EasyUAClient opc, String device) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 120
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.GetOpcForCall(String tag) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 147
at Mesabi.MixVision.Opc.Service.OpcServiceLibrary.ReadOpcTags(String server, String[] tags, String sender) in C:\Working\Mesabi\OpcService\Mesabi.MixVision.Opc.Service\OpcServiceLibrary.cs:line 0
*******************************************************************************************************************************************
The customer upgraded the quick OPC dlls from 5.50 to 5.54 as well as updating the server to TOP Server 6.6 from V5.21. Since he updated the Dlls he started to get the first exception (The process was terminated due to an unhandled exception) which if I recall correctly, this could possibly be an issue with the "Boxing". We suggested to him to disable the boxing using these instructions - kb.opclabs.com/How_to_disable_prerequisites_boxing - even though we were under the impression that his issue was fixed on version 5.54. but we wanted to see if this had any effect. Ever since he disabled the boxing, he has not seen the exception thrown again; however, the second exception is occurring 2 to 3 times in an hour pretty consistently.
This is only occurring on the production environment which has been updated to the same quick opc version. He has also updated the .NET Runtime to 4.6.2. He is running his service on Server 2016. Have you seen this behavior before? Do you jave any suggestions on what might be the issue? Thanks in advance.