Is it ok to see the interface in clr callstack?

Question

I have an asp.net application that crashes. There is an entry in the Windows event log containing this column:

Exception type: EntryPointNotFoundException Exception message: Entry point was not found. at ***.Interfaces.Portal.Repository.ILookup.get_LookupDataCollection() at ***.Portal.Repository.Lookup.GetLookUpValue(ILookup lookup, Int32 index) at ***.Portal.Repository.Lookup.GetLookUpValue(ILookup lookup) at ***.HttpModules.RuntimeHttpModule.SetPageUrlInfoInContext(PageUrlInfo pinfo) at ***PortalRuntime.HttpModules.RuntimeHttpModule.BeginRequest(Object sender, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) 

This only happens on the client machine, and I could not play it locally. As you see above, there is an interface ( ILookup , which is really an interface, not a class).

I built a similar pattern (method called via interface). Visual Studio 2015 is smart enough to show this:

 ConsoleApplication2.exe!ConsoleApplication2.Lookup.GetLookupId(ConsoleApplication2.ILookup lookup) Line 37 C# 

But you still see the class that implements the method. I also attached to my sample using windbg and printed the stack when the application sits at a breakpoint in a method that is called through the interface: the interface was not on the stack.

Here is my question:

• Is it okay to see the interface in clst callstack (especially without a class that implements it)? It seems I have never seen such a collage before ... Has anyone else? (I mean this at all, regardless of the second part of my question)

• Here is a very similar question: @Hans Passant in his first comment says "inability to solve an implementation method for an interface method" and the OP says that "you already answered my question with your first comment." So is this really the root cause? Does anyone know of a fix for this? Or is it just a special version of the CLR?

Answer 1

I can explain why you see it a little, it will not be useful to solve your problem. I also do not know how the CLR associates interface methods with their implementation; it is insanely optimized.

The problem is that jitter must generate code for a method that contains an invocation of an interface method. But he still cannot know the identity of the object reference. This is not 100% accurate until the code is executed. So what he does is to allocate a stub, a place for the target method. And generates a CALL statement for this stub. The actual name of this stub method does not matter; it will disappear again when the real target method is resolved.

The stub itself generates a call to the CLR to resolve the target method, now knowing the true identification of the object reference and thus which specific implementation method to execute. And corrects the machine code, so the CALL address is replaced. Therefore, the next time the method is executed, you do not pay the price for binding the method, and the call is executed at the maximum possible strain rate.

As noted, the name of the stub does not matter because it is temporary. Giving it an interface method name is very useful for diagnosing a MissingMethodException. A good idea.

The real problem is that the assembly that was loaded is not the one with which you created your code. Probably the old one you forgot to redistribute. Or you just forgot to rebuild it when you changed the interface because it is not part of the solution. Thus, it does not have an implementation of the interface method, the CLR detects this very late when the stub is executed. Thus, you see the name of the stub method in the call stack.