When compiling an executable in Release mode -with code optimizations enabled- the compiler may opt to inline functions that meet certain criteria in order to improve
This is not a definitive answer but i tried to decorate a simple method that only does division by zero with the [MethodImpl(MethodImplOptions.AggressiveInlining)]
attribute which in .NET 4.5 gives a hint to the JIT (which actually performs inlining) to inline a certain method and when i ran the program in release mode, the exception was reported from the calling method, not the one with the division. On the other hand, as Hans said, Methods with throw statements and complex flow logic aren't inlined. This Article on MSDN blog (although from 2004) gives you an overview on how inlining is done by the JIT.
It depends how the exception was thrown. If you use the throw statement then you don't have a problem, the jitter won't inline methods that contain a throw. Something to be aware of when you need a property setter to be fast btw.
However, if the exception is caused by normal execution, like a NullReferenceException or IndexOutOfRangeException etc, then yes, you don't see the name of the method on the stack trace if it was inlined. This can be a bit bewildering but you usually figure it out from the source code of the calling method and the exception type. Hopefully it is relatively small. The [MethodImpl(MethodImplOptions.NoInlining)]
attribute is available to suppress inlining. By the time you discover it would be helpful it is usually too late ;)