0

The error shown in the following screen shot occurs sporadically:

enter image description here

The application itself is in unmanaged C++, using COM objects, and .NET objects (in C# and VB) via COM interop.

Only two functions from the stack trace are in our code

McWrapperControl.ControlHost.InvokeMethod

Public Sub InvokeMethod(ByVal Member As String, ByVal NumArgs As Integer, ByVal Args As Object)

  Try

    Dim ArgsType As Type = Args.GetType()
    Dim ArgsArray As Object

    If NumArgs = 0 Then
      ArgsArray = Nothing
    ElseIf ArgsType.IsArray Then
      ArgsArray = Args
    Else
      ArgsArray = {Args}
    End If

    InvokeMethod_ArgsArray(Member, ArgsArray)

  Catch ex As Exception
    ReportError.ShowErrorDialog(ex, "")
  End Try

End Sub

and McWrapperControl.ControlHost.InvokeMethod_ArgsArray

Public Sub InvokeMethod_ArgsArray(ByVal Member As String, ByVal ArgsArray As Object)

  Try

    Dim Target As Object = ContainedControl()
    If Target IsNot Nothing Then
      Dim TargetType As Type = Target.GetType()
      TargetType.InvokeMember(Member, BindingFlags.InvokeMethod, Nothing, Target, ArgsArray)
    End If

  Catch ex As MissingMethodException
    'Ignore this error
  Catch ex As Exception
    ReportError.ShowErrorDialog(ex, "")
  End Try

End Sub

In this case I am fairly certain that a MissingMethodException is occurring, but this should be caught and ignored. Obviously, I might be able to prevent this error by checking for the existence of the named method, before trying to invoke it.

Aside from that, can anybody explain what might cause this recursion?

Phil Jollans
  • 3,605
  • 2
  • 37
  • 50
  • It can't make it to the Catch clause, it is still trying to construct the MissingMethodException object. Which requires a resource lookup to produce the Message property value. Something seems to be amiss with the AppDomain, very mysterious how it recursed back into ControlHost.InvokeMethod(). It is this recursion that produced the hard crash. But the point of custom-hosting the CLR is often to tinker with the AppDomain assembly resolution mechanics, with stack frames in unmanaged code we wouldn't see back, in code we cannot see. – Hans Passant Oct 04 '19 at 12:48
  • What calls InvokeMethod in the first place? Where/when is this method called? – Simon Mourier Oct 04 '19 at 13:03
  • The InvokeMethod is called via COM interop from a function in C++ on the MainThread. That function is called from a different thread using a COM interface which was passed into the thread using CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream. (Remember them? It was programmed in the last century.) The .NET object is created via COM interop, which must create the AppDomain under the hood. We do not do anything explicitly with the AppDomain. – Phil Jollans Oct 04 '19 at 15:07
  • Why the CLR would call back this InvokeMethod method of yours? I suppose this InvokeMethod code is automatically called when "something" starts up (a static somehing (ctor), a lazy, a thread, an AppDomain, etc.). Hence when the first error occurs, the systems kinda initialize something else that calls that code again. – Simon Mourier Oct 04 '19 at 15:32
  • Could it be, that it is not recursive, but that the worker thread is making repeated calls into the man thread? This would mean (1) that the worker thread doesn't wait for the inter-thread call to complete (which I find a bit surprising) and (2) that the main thread is blocking in a state where an inter-thread call can be handled (which I guess means pumping its message loop). – Phil Jollans Oct 04 '19 at 15:56

0 Answers0