If a managed debugger tries to place a breakpoint at the start of an IL stub, the debugger uses the ILStubManager to place the breakpoint at a location where the user would expect it. For example, for P/Invoke calls it places it at the start of the native call, and for reverse P/Invoke calls, it places it at the start of the managed method.
The ILStubManager doesn't correctly handle struct marshaling stubs. They fall down the else case at the bottom that assumes that the method at that point is a COM call. From that point on we get into a very bad state and AV down the stack, which propagates up as an ExecutionEngineException.
This is the root cause of microsoft/CsWinRT#264.