Skip navigation

Probe the Secrets of the Stack Trace

Learn how to find useful clues in the stack trace to help you cure programming headaches.

Troubleshooting Tricks


TECHNOLOGIES: Stack Trace | Exceptions


Probe the Secrets of the Stack Trace

Learn how to find useful clues in the stack trace to help you cure programming headaches.


By Don Kiely


Frequently I'm asked for help with resolving exception messages generated by ASP.NET applications, and I encounter many more such requests on the forums. All too often, the question is of the form, "Help! I'm getting this error: 'Object reference not set to an instance of an object.' How do I solve it??!? I'm on a tight deadline!" Of course, my only response can be that it's impossible to be of any help without more information. Then I ask for two things: the code of the procedure where the exception occurred plus any other relevant code (hoping my inbox isn't soon plugged with 10 megs of "relevant" code) and the exception message's complete text (see Figure 1).


Sometimes I must go back and forth with the person several times because they don't believe I really want the entire text of the message, including all the nonsense junk at the bottom that has cryptic object names, strange numbers, and method names that aren't in the custom source code. Yes, all that blather at the bottom of the page is valuable. It's called a stack trace, and it provides valuable clues about how to resolve particular problems.


Figure 1 shows an example of an exception message we're all painfully familiar with.


Figure 1. This is a typical error message. All the information on this page is vital - including the stuff at the bottom, which is called the stack trace.


I generated this simply by including this line of code deep within a nested procedure on an .aspx page:


Throw New NullReferenceException


Simple enough. In this contrived example, the error probably is easy enough to find and diagnose. The exception message provides the offending code, and usually you simply can look at that line, or maybe a couple before it, to figure out what's wrong. But that's really only the case when the exception is raised by your code.


Things get trickier when the exception is raised by code deep within the .NET Framework that executes in response to something in your code. But your code calls a framework method, which calls another framework method, which calls another method, when ... zap! - that last method raises an exception. In this case your procedure is far below the top of the stack trace. That's a bug in the framework, right? Maybe, but it's more likely because you either called the first framework method with parameters that Microsoft didn't anticipate - don't underestimate an ASP.NET programmer's creative abilities - or some environmental condition didn't meet the needs of the deeply nested method.


In cases like this you can look at your own code all day long and never figure out what's up. But by carefully examining the stack trace you can pick up many clues about what is happening. Examine the .NET documentation for the objects the framework is using as it moves deeper into the framework. What kind of data do these nested objects expect that perhaps they aren't getting? Are there inconsistencies in your parameters that are causing confusion in the framework? I've found this can provide just enough information for me to figure out the problem. And if all else fails, you can run ildasm on framework DLLs and really get into the messy details of what's going on. Thankfully, it's rare that I need to probe that deeply.


Incidentally, as you explore the stack trace for your custom procedures, be aware that the line numbers are actual lines in the code module's text, as though all regions are expanded. If you go to the file and can't find the line number for any of the items in the stack trace, you might have an unexpanded region.


Next time I'll explore a way you can generate a stack trace anytime in your own code - even when it hasn't thrown an exception.


The sample code in this article is available for download.


Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.