The Art of Debugging – A Developer’s Best Friend- Intro – Lesson 1- Repost

Art is the process or product of deliberately arranging elements in a way that appeals to the sense or emotions. It encompasses a diverse range of human activities and I think debugging is an art form. There’s nothing more beautiful (almost nothing) than watching your errant code expose it’s semi-flawed algorithmic beauty. And nothing appeals to my emotions more than make my code more robust and more efficient after watching the debugger execute it one line at a time.

John Robbins is the pre-eminant debugger of today. You may check out his book for more information. Much of this material is based on his work.

www.amazon.com/Debugging-Microsoft-NET-2-0-Applications/dp/0735622027

WinDbg – Debugging without source code

I used to be a Rapid Response Engineer (RRE) for a few years at Microsoft. That means I got on planes, flew to customer sites, and tried to figure out why code isn’t operating the way it is supposed to. Many times it manifests it self as slow performance or a memory leak.

Reactive debugging on production systems requires non-intrusive debugging. The tool of choice iss WinDbg, because it allows you to debug code without source code. If you are lucky you could get your hands on the symbol files, which are generated by the compiler when the developers compile their code. This allows you to atleast see N function names and variables. In the absences of symbols files all you see gibberish, functions and variable names that have been mangled.

Name Mangling – Who does it and why

In software compiler engineering, name mangling (more properly called name decoration, although this term is less commonly used) is a technique used to solve various problems caused by the need to resolve unique names for programming entities in many modern programming languages.

It provides a way of encoding additional information about the name of a function, structure, class or another datatype in order to pass more semantic information from the compilers to linkers.

Debugging in production systems

Often times, when debugging production systems, you cannot afford to be intrusive. If you are troubleshooting a production system, you need to be as least invasive as possible. Installing Visual Studio is not an option on a production web server. You can download WinDbg below.

Enter Visual Studio 2008

This blog is about Visual Studio. So the tips and techniques I talk about are things you can do with Visual Studio.

Here are the topics we want to cover

Stack Window Breakpoints

Sub Expression Breakpoints

Quickly Breaking on a Function

Breakpoint Hit Count

Breakpoint Condition

Assertions on the Fly

Filter Breakpoint Modifier

Tracepoints

The Amazing Data Tip

Calling Methods in the Watch Window

Testing Tricks

Make Object ID

Generational Objects

Set Next Statement

Threading Help

Setting up .NET Reference Source Code Stepping

Setup and Configuration

The following software packages must be installed or settings set on your computer in order to use these demo materials:

Visual Studio 2008 Professional-Express Edition

Visual Studio 2008 Service Pack 1

Click here for the download sample code used in this blog

Stack Windows Breakpoint

This is the project that we need to learn debugging with.

Many different types of applications can be debugged with the techniques we discuss here:

WPF

ASP.NET

Silverlight

WCF

WinForms

MVC

Mobile Development

Workflow

C++

Language Agnostic

C#, Visual Basic, Debugger Is Language Agnostic

Advanced Breakpoints

Stop in break mode only when you want to

Customize actions when you hit breakpoint

We want to know why and where to use adv breakpoints

Solve in a day versus several weeks

You should start on paper

Develop a strategy before blindly going debugging

You need both the Visual Studio projects and the PDB files

These allow you to work with advanced features

Assemblies in address space are referenced by pdb files

Setting a breakpoint

Now start debugging.

Notice the call stack is displayed. And as we would expect, we can see that we are resting at the breakpoint in a deeply nested call stack.

You can see that our breakpoint is at Doh(). Notice the the buttonDeepStack_Click called “Do()” and that “Do()” called “Re()” and so on.

But what if we wanted to break at the top of the stack - buttonDeepStack_Click()?

The answer is to set a breakpoint within the “Call Stack” window. We can use the “Call Stack” window to set breakpoints.

You can see that we stopped at “buttonDeepStack_Click”. This approach makes it convenient for to break anywhere in the call stack depending on the needs of your debugging experience.