Your debugging experience - I want to hear from you

So I would like to hear from you guys. I am getting ready to start working a lot on creating some debugging videos (I have already created one and just have to clean it up a little). But it got me thinking that I would would to hear how you guys go about troubleshooting the problems that you face.

So I would be really interested in knowing the tools you use, what your steps are, and how you progress through tracking down an issue. If you want, you can tell me about multiple types of issues, or just pick the one that you see most often.

Please include the commands that you use out of sos.dll, if you troubleshoot using that. Are there certain commands that you always run? Or always want to see the output from?

I have my own ideas, but I want to give you a chance to tell me what you do first. The more details the better.

It would be great also to know how you go about looking for additional information. Do you immediately go to one site looking for answers? Start searching? Or what are your steps?

Please feel free to comment about troubleshooting .NET, ASP.NET, IIS, or any other Microsoft technologies around the web (Silverlight, Ajax, etc.).

One of the things that I am thinking of is creating are commands which would be the command to run to start troubleshooting a given problem. For instance, if you have high memory, always run this command and it will get you going in the right direction.

Published 15 May 08 11:27 by Tom

Filed under: ASP.NET, Debugging, IIS, .NET

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# DotNetKicks.com said on May 15, 2008 11:28 PM:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# Sean Patterson said on May 16, 2008 12:55 PM:

Greetings Tom,

I've been following your blog a little bit now and in a lot of ways, I run a completely different gamut for my ASP.NET debugging.

I got hooked on log4net a while back. I love the infrastructure it provides and by default, all my web apps are configured to log any caught and unhandled exceptions by dumping the exception into the log.

By doing things this way, I can have a user friendly message displayed to the end user when something goes wrong, but still have a full dump of the stack trace for debugging purposes.

Since I don't always have access to the server itself, I wrote a little web application (actually in CodePlex - http://www.codeplex.com/hacksaw) that will allow me to view the log entries. I pull up the log and find the error in question.

Fortunately in my environment, 9 times out of 10, it winds up being a pretty simple error like a missing file or a missing parameter, which the end user can use the application to update.

If things are worse than that, I simply modify the log4net configuration to go into DEBUG mode, which I have coded to dump additional information, such as start/end of methods, parameters passed in, and the like.

After that point, I'll turn on the ASPNET tracer (which will also display the log4net items as well) and see if that opens up any doors.

The final step for me comes to jumping back into my development machine and stepping through the debugger at the points of interest. Fortunately I haven't had to do this too many times, but I don't believe I'm running any of the high end stuff you're doing around here.

Heck, I'm still learning about sos.dll and all those tricks, hence the reason I'm following this blog 8^D Keep up the great work!

# Tom said on May 16, 2008 2:04 PM:

Sean,

Thanks for the comment. That is some really great information and that is exactly what I am looking for. I am trying to figure out the best way to create something that can be used by everyone. I also want to see what we can do to help without the need for dumps so this is great information.

Name (required)
Your URL (optional)
Comments (required)
Remember Me?

Search

This Blog

Home
Email

All my posts are provided "AS IS" with no warranties, and confer no rights. All the expressions expressed herein are entirely my own and not necessarily those of Microsoft. In addition, thoughts and opinions often change. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.

See who links to this blog