Decrypting the YSOD, techniques to the mayhem.

Question

How many can relate do this? hehe

On a more serious note, what are the first things you look for when you see the yellow screen of death?

Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).

What techniques do you use to debug the problem?

I must admit, I still use response.write more than I should. I just get lazy going through the debugger.

Hoping to get learn some more debug techniques from you guys. (specific to the YSOD since I'm more into web apps).

Answer 1

If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.

For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.

I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.

Answer 2

I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.

In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.

Answer 3

the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.

I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.

Also, opening up the immediate window while debugging is gonna make your life even more happy.

Answer 4

Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.

• Add properties such as the SQL statement being run. Two display message text fields, one for display to users, one for display to developers (in debug mode) Who is the logged-in user. Get all the form variables so you know what they were trying to enter.

• Log the errors somewhere (event log is good, if you can access the web server; logging to the database is less successful when so many exceptions are inability to access the database).

• Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.

• Create a custom error page. When in debug mode, the custom error page displays everything. When not in debug mode (production), display only selected properties of the custom exception.

Investing the time up front to do this will save you many hours of anguish later.

Answer 5

Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.

It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.