.NET Debugging for Rookies

Sure, you get stuck. But these five steps will help you get back on track.
Posted October 1, 2008

Sara Chipps

Sara Chipps

(Page 1 of 2)

Dubugging is either the best or worst part of being a developer, depending on your style. Myself, I can deal with the tiny bugs, but when the doozies come around I am easily frustrated.

This has been especially hard lately because I'm a lone developer now on my current project, and I don't have colleagues to come take a look when I'm so frustrated that I just have to step away. So, I’ve assembled quite a system to ensure that the root of the problem is found and fixed and my app is back to being a well oiled machine ASAP.

I probably would have enjoyed a how-to like this before I got started, so I thought I would share it. This is aimed toward the greener folks, but you experts may get a few ideas as well. Many of these principals apply to all languages, so even if you're not a .NET developer, read on.

Step One: The Basics. The worst phrase to a .Net developer? Object reference not set to an instance of an object. However that's right where you start, sometimes the stack trace output can be a little overwhelming, but think of it as your first clue.

Look for the names of controls or classes. Usually it will at least tell you approximately where to start looking for your problem. Also ask yourself some questions: What have you changed since before this problem started? What's the last thing you were working on? Think about your syntax. Anything you could be missing?

Step Two: Visual Studio Tools. Ok, here's where you find out if it's going to be an easy one or not.

Place a breakpoint somewhere before where your error originates (what the stack trace tells you or where you made your most recent changes). Then step through and step into your code in order to find the line that’s causing your app to throw the exception.

After you find it you can mouse over each of the components and drill down into its properties within VS. You can also use the immediate window to check values of different objects at runtime, or add a watch on one of them to see where and how they change. Use the great logic that made you a programmer to keep narrowing down what could be causing it. But if you still can't find it proceed to step three.

Step Three: Other Very Useful Tools. Now it's time to dig a little deeper, if you can't find the issue behind your code it's time to move to your other layers.

SQL Profiler, which is included with the MS SQL suite, is a great way to see what is being passed back to your database if you are using MS SQL Server. If you are using My SQL there is MySQL Query Profiler, and for Oracle there is EXPLAIN PLAN and tkprof.

Sometimes the error can be caused by a badly formed query or incorrect data, and that's the way to find out. To inspect your HTML as it goes to the browser there is a great and free tool called Fiddler. Fiddler will break down all your http traffic on your local machine. You can set breakpoints and make real time changes. I have found it extremely useful in checking out my site (and others).

Firebug is a great CSS/HTML/JavaScript troubleshooter and debugger. It's a free add on for FireFox (the developer's browser) and though Visual Studio now has JavaScript debugging I still find it to be the most reliable.

Still stuck? Okay, on to step four.

Page 1 of 2

1 2
Next Page

Tags: .NET, Oracle, developer, server, programming

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.