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.
Download the sample project – debugging.zip |
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
Lession 1 – Using the Call Stack Window and Breakpoints |
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.
