Debugging ASP.NET on a Production Server 101


So I thought I would put all the information together in one place that I have been creating over the past few months.  I’ll try to go through all the steps and the different things that you will need to use in order to track down a problem.

Realizing there is a problem

So the first step is finding out there is some kind of problem in the first place.  There are a number of methods that you could use to find this out:

  • Visitor of your web site reports a problem
  • Review Event logs and see some entries in there regarding an issue
  • Monitor Perfmon and see values that are out of acceptable values, like described in ASP.NET and Performance
  • Other means (reviewing logged data, receive email, etc)

Determine the problem type

Once you know there is a problem, the next step really depends on what the problem is.  It could be something as simple as checking to make sure the network cable is connected properly.

Once you know the type of problem, then you can follow the steps I have laid out to troubleshoot it.

Gather data

The first thing would be to gather the correct data to see what is happening.  You can follow this link to see the full list of issue types and how to get the correct data for each, ASP.NET Tips- What to gather to troubleshoot.  If you come across a situation that isn’t covered here, please let me know.

There are some other ways to get data, for example, ASP.NET Debugging – ASP.NET Tips- How to use DebugDiag to track down which is for performance problems.

Debugging the issue

So now that we have the data we need, it is time to analyze it.  This can be a difficult task depending on the scenario that you are dealing with.  There is a lot of documentation around about using SOS and Windbg to troubleshoot things.  That is the best means as you can always track down what is happening.  For more help on actually tracking down the problem from the data, I would suggest looking at my blog for the particular issue you are having.  I have many posts that help with the situations:

If all else fails, you can always look at the Debugging or SOS tags to find a whole lot of information.

Additional Information

So what if you don’t have a problem and just want to learn about these steps and tools?  Well, one way would be to read through the various information found here.  Another way would be to actually go through some of it.  Tess has some great debugging labs around this stuff that you can find here.  You may also want to look at her 21 most popular blog posts.

kick it on DotNetKicks.com

Comments (8)

  1. So many good articles and resources I have found over the last month or so. Here is a good sampling of

  2. This Week on C9: Netflix, Extension Methods, Debugging, oh my Oh, did I also mention that they showed

  3. gOODiDEA says:

    DebugDebuggingASP.NETonaProductionServer101LogparserScenario9:Findoutwhatisthepeak…

  4. gOODiDEA.NET says:

    Debug Debugging ASP.NET on a Production Server 101 Logparser Scenario 9:Find out what is the peak time

  5. I’ve just finished writing up an e-mail for some new people in my team about starting Debugging and the

  6. ASPInsiders says:

    Bunch of stuff I’ve been meaning to blog about recently, in no particular order: The SideShow Team Blog

  7. Some time back, I gave a talk at the Dallas ASP.NET User Group on the topic of "Debugging with Visual