c# - Is it normal to see an interface in a clr callstack? -

i have asp.net application, crashing. there entry in windows event logs contains callstack:

 exception type: entrypointnotfoundexception      exception message: entry point not found.    @ ***.interfaces.portal.repository.ilookup.get_lookupdatacollection()    @ ***.portal.repository.lookup.getlookupvalue(ilookup lookup, int32 index)    @ ***.portal.repository.lookup.getlookupvalue(ilookup lookup)    @ ***.httpmodules.runtimehttpmodule.setpageurlinfoincontext(pageurlinfo pinfo)    @ ***portalruntime.httpmodules.runtimehttpmodule.beginrequest(object sender, eventargs e)    @ system.web.httpapplication.synceventexecutionstep.system.web.httpapplication.iexecutionstep.execute()    @ system.web.httpapplication.executestep(iexecutionstep step, boolean& completedsynchronously) 

this happens on customer machine , not able reproduce locally. see on top there interface (ilookup, interface, not class).

i built similar sample (method called via interface). visual studio 2015 smart enough show this:

consoleapplication2.exe!consoleapplication2.lookup.getlookupid(consoleapplication2.ilookup lookup) line 37  c# 

but there still see class implements method. attached sample windbg , printed stack when application sits in breakpoint in method called via interface: interface not on stack.

here question:

• is normal see interface in clr callstack (especially without class implements it)? think have never seen such callstack before… else? (i mean in general, regardless of second part of question)

• here similar question: @hans passant in first comment says “failure resolve implementation method interface method” , op says “you answered question first comment”. root cause? know fix this? or special clr version?

i can explain why see little bit, not helpful @ resolve problem. nor know enough way clr binds interface methods implementation, crazily micro-optimized.

at issue jitter must generate code method contains interface method call. cannot yet know identity of object reference. that's not know 100% accurate until code executes. allocate stub, place holder target method. , generates call instruction stub. actual name of stub method not relevant, going disappear again when real target method resolved.

the stub generates call clr resolve target method, knowing true identity of object reference , specific implementation method needs execute. , patches machine code call address replaced. next time method executes don't pay price of method binding , call runs @ maximum possible warp speed.

as noted, name of stub not matter since temporary. giving name of interface method very helpful diagnose missingmethodexception. idea.

the real issue assembly loaded not 1 built code with. old 1 forgot redeploy. or plain forgot rebuild when changed interface because not part of solution. doesn't have implementation of interface method, clr discovers late, when stub executes. see stub method name on call stack.