Exception Handling: StackFrame Capture not capturing last level method call in release mode

i trying print exception details frame frame along other debug info (code below). in code can see dummycall3 throws , applicationexception , expectation stack trace have information regarding dummycall3. below behavior getting .net 4.

• using "debug" build, when run it, expected results (dummycall3 > dummycall2 > dummycall > runtest)
• using "release" build however, dummycall3 method somehow missing stack trace. (dummycall2 > dummycall > runtest)
• i add dummy statement in dummcall3 method before throw exception, , rerun using "release" mode , works expected strack trace info (dummycall3 > dummycall2 > dummycall > runtest)
• if switch framework version .net 3.5 works expected in both release , debug modes?

i know if behavior design or bug? if design, reasoning behind it. appreciate input on this.

 

    class stackframetest    {      public void runtest()      {        try        {          dummycall();        }        catch (exception ex)        {          console.writeline(ex.tostring());        }        }        private void dummycall()      {        try        {          dummycall2("shree", 22);        }        catch        {          throw;        }      }        private void dummycall2(string name, int age)      {        try        {          dummycall3(22, "shree");        }        catch        {          throw;        }      }        private void dummycall3(int age, string name)      {        //int = 10 + datetime.now.year;        throw new applicationexception("instrumented exception");      }    }    

 

thanks

shredhar

this because system decided "inline" call.  often do "short" methods.  replaced call copy of code method.  thus, there no call appear in call stack.  reasoning performance.  stack maintenance can omitted cpu branching due call.  debug mode, inlining not occur complicates debugging in way have observed. 

you can add [methodimpl(methodimploptions.noinlining)] right above method tell system may not inline method.

whatever do, do not consider using debug build in production.  can cause obscure problems.

> if switch framework version .net 3.5 works expected in both release , debug modes?

the aggressiveness of these optimizations varies depending on clr version.

 

.NET Framework  >  Common Language Runtime Internals and Architecture