title: Wrong line numbers in stack trace
body: <h2>The problem</h2>
  
  <p>On our ASP .net website I keep getting wrong line numbers in stack traces of exceptions. I am talking about our live environment. There seems to be a pattern: The stack trace will always point to the line that contains the method's closing curly brackets.</p>
  
  <p>For Example:</p>
  
  <pre><code>public class Foo
  {
      public void Bar()
      {
          object someObject = null;
          someObject.ToString();
       /*
            arbitrarily more lines of code
       */
       } // this line will be the one that the stack trace points to
  }
  </code></pre>
  
  <h2>More details</h2>
  
  <ul>
  <li><p>To be clear: This does not only happen for some method(s), it happens for every exception that we log. So I would rule out (JIT) optimizations here, that might lead to line numbers being seemingly randomly off. What bothers me is, that the wrong line numbers seem to consistently point to the closing curly brackets of the containing method.</p></li>
  <li><p>Note that before .net 4.6 there actually was a bug in the framework, such that if you compiled targeting x64, exactly this would happen. However, Microsoft confirmed that this has been fixed. Also running a minimal example app for this, reaffirms their claim. But for some reason it still happens on the web servers.</p></li>
  <li><p>It puzzles me even more that it does not happen in our test and development environments. The test and live systems are pretty similarly set up. The only real difference is that live we are running Windows Server 2012, while on the test system we are still using Windows Server 2008.</p></li>
  </ul>
  
  <h2>What I have checked</h2>
  
  <ul>
  <li>pdb files are valid (tested with chkmatch)</li>
  <li>Compile time code optimizations are not the issue</li>
  <li>The aforementioned bug in .net before 4.6 cannot be reproduced with a minimal example</li>
  <li>.NET versions are exactly the same</li>
  <li>Build comes from the same deploy script</li>
  </ul>
  
  <p>Any clues towards solving this problem are highly appreciated. If you know anything that we could check, please let me know. </p>