Last year 2008 was challenging, amazing and exciting all at the same time. I’ve had a lot of interesting experiences and situations alike that goes from moving countries (Venezuela to Australia), joining CustomWare, my first speaking engagement in Tech-Ed and so on. I’ve learned a lot generally speaking so I hope this year 2009 can be better than the previous one. As developers, we can’t escape the fact that our code is not bug free (we wish it was but life ain’t perfect) so this post is about some useful debugging tips and options we have available
Option #1 – Visual Studio .NET Debugger
This is our first line of defense, but it’s missing 99% of the times on a production environment. It allows to set breakpoints, add watches, evaluate expressions, view memory and its disassembly and something even cooler… We can step into .NET Framework code (Image 1)
Option #2 – CorDebug
It’s a pretty cool tool which allows us to debug .NET code using the command line. It takes some time to get used to the commands but once we do it, it’s pretty straightforward. It’s highly recommended to have the symbols files (PDB) required to step into the code. If we don’t have it then we’re going to see the code in Assembler. Let’s take as an example the Test.cs source file (Image 2), it’s a very simple application written with “Visual” Notepad.
Then we’re going to compile it using the CSC from the Command Prompt. We can either generate symbols/debug information or not with the following switches:
· Generate Debug Information
csc test.cs /platform:x64 /debug
· Don’t generate any Debug Information
csc test.cs /platform:x64
Once we’ve built our assembly/application we can launch CorDebug and start debugging it. We can either let CorDebug launch the application for us or we can attach it to the selected process by ourselves. Image 3 depicts the CorDebug “interface”.
The yellow rounded rectangles indicate:
1. Listing of managed applications running
2. Attach the debugger to process 1372
We can execute ? anytime to get information about available commands. The following image shows CorDbg launching the application for us and we step into the code (The lines are retrieved from the PDB file and code executed outside our program is displayed in Assembler). The colour reference (Image 4) for the rounded rectangles is:
· Light Green: CorDbg launching c:\test.exe
· Light Blue: Assemblies loaded
· Yellow: Stepping into the code
· Red: Displaying and modifying variables
· Grey: Stack trace at that moment
· Cyan: Modules loaded plus Application Domain ID
Option #3 – WinDbg (Windows Debugging Tools)
It’s a multipurpose debugger that can be used to debug user mode applications, drivers and the operating system itself in kernel mode. It’s very useful to debug kernel-mode memory dumps, created after an application crashes or when experiencing a “BSoD”. This tool allows to step into the code if PDB (symbol file) is present (Image 5).
WinDbg allows loading of extension DLLs that can augment the debugger's supported commands and allow for help in debugging specific scenarios: for example, displaying an MSXML document given an IXMLDOMDocument, or debugging the Common Language Runtime (CLR). These extensions are a large part of what makes WinDbg such a powerful debugger. WinDbg is used by the Microsoft Windows product team to build Windows, and everything needed to debug Windows is included in these extension DLLs.
Option #4 – CLR Profiler
Believe it or not but this tool helped me a lot 4 years ago when one of the projects I was engaged on at that time started to act “weird”… By using CLR Profiler and Windows Monitoring and Performance tools I was able to find a memory leak issue with BSTR objects. CLRProfiler is a tool that you can use to analyze the behavior of your managed applications which is focused on analyzing what is going on in the garbage collector heap (Image 6) and you can get an overview of your application’s memory usage (Image 7).
Option #5 – .NET Reflector
Originally developed by Lutz Roeder and now by Red Gate Software, this tool is really handy and a “must-have” in every .NET developer toolbox because it allows you to Disassemble and analyze .NET assemblies (Image 8) so you can check and step into .NET code without having the source files.
Option #6 – Fiddler
Have you ever wanted to sniff HTTP requests/responses? If that’s the case then you might find Fiddler useful. It’s a light-weight sniffing tool which allows developers see what’s happening between client/server HTTP transmission (Image
9) Option #7 – Microsoft NetMon (Network Monitor)
A couple of months ago I had an issue related to Kerberos, it seemed that the Kerberos ticket was getting lost somewhere… My best choice for this kind of situations, NetMon (Image 10). It’s a complete sniffing and network monitoring tool by Microsoft.
Option #8 – Windows’ performance and monitoring Tools
Task Manager, Performance Monitor can make our lives easier if we know how to use them and most important… Add the right performance counter to determine and detect any possible problem.
Hope this helps,
Kind regards,
Angel