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.
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:
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.