Wrong line numbers in stack trace (release)

Question

Sometimes we receive stack traces from our customer with wrong line numbers. It happens not so often, but sometimes it puzzles us.

Customers have release assemblies with optimizations and with "pdb only" debug information.

And yes, we compare line numbers with exactly the same version of code the customer has.

And yes, customer has right pdb files.

And no, this difference in line numbers can't be explained with the method inlining (compiler optimization).

And no, we don't use any AOP tools, like PostSharp.

Any ideas why does it happen?

Answer 1

Not a .net expert, but at least in other languages, when high compiler optimizations are chosen, the compiler may make significant reordering of code. This can and often does make it very difficult to pin the source of an error down to a particular line. If the compiler is able to make optimisations across basic blocks, then this effect can be very significant, putting the apparent line location in a totally different part of the source file.

Answer 2

If you use lots of compil optimization, the compiler might move parts of your code i guess.

Best way to debug, is to use Reflector on the dll that your client actually use. Using line numbers of the stacktrace, you'll find exactly what lines of codes are called when the app crashes.