How do I interpret this C# stack trace? Error on line zero.

Question

Hi all,

I'm getting a "Object reference not set to an instance of an object" error with the following at the top of the stack in the logs (C# ASP.NET application):

@Web.UI.UserBrochurePage.Page_Load(Object,EventArgs)+25 Line: 0  
@System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr,Object,Object,EventArgs)+0 Line: 0  
@System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object,EventArgs)+26 Line: 0  
@System.Web.UI.Control.OnLoad(EventArgs)+38 Line: 0 
@System.Web.UI.Control.LoadRecursive()+35 Line: 0
@System.Web.UI.Page.ProcessRequestMain(Boolean,Boolean)+1160 Line: 0

The things I don't understand:

1. Every error is on line zero
2. The most interesting error (top one - in my code) has a "+25" after it. I never understood what those meant, although I assumed they were character offsets on the line... if that were the case, it wouldn't point to anything meaningful (the middle of a parameter declaration).

This is a production system in release mode, but I still can usually get line numbers out of the stack trace objects. In this case, unfortunately, the error does not reproduce on our debug systems, so I'm stuck doing my best with this.

Any advice would be appreciated.

Thanks, Tom

Answer 1

See this question for information about understanding the offsets. I suspect you should really just build you production binaries with debug information in - it's going to be a lot easier than examining the IL to work out what offset means which line.

Answer 2

I think that you see "Line 0" for every call in the stacktrace because your code is compiled in Release mode instead of Debug mode. In debug mode, your code will be compiled to include a debug symbols file (.pdb). When this file is available, your exception stacktrace will accurately represent the line numbers.

In any case, only the line number of your Page_Load is significant because the rest are internal calls of the framework assemblies.

The +xx number after each stacktrace entry is apparently the "byte offset into native code". I do confess that it originally appeared to me that it was the time of execution in ticks or milliseconds.