[X]

Microsoft.Net Debugging and Tools (.Net Debugging Series)

Debugging is one of most common activity that every developer has to deal with in its day to day development life cycle. So It is very important that one should know the proper debugging technique and also could use the correct tools for debugging that particular issue.

But quite often it happens that developers are using wrong tools trying to investigate a particular problem. Sometimes developers are lucky to identify the exact place of code for the problem. And some times in spite of extensive code review still the problem is not caught because may be they are looking at wrong place or incorrect tool/no tool is used for debugging.

There are many powerful and free investigative tools which can dramatically reduce the troubleshooting time. These tools are very efficient and used by most of the professional developers. As fact we should know that a single tool can not address the every problem as each of these tools focus on a specific category. So knowing when and how to use each tool is very important for debugging .net applications.

Debugging Tools for Windows

URL: www.microsoft.com/whdc/devtools/debugging/default.mspx

Debugging Tools for Windows 32-bit Versions
Debugging Tools for Windows 64-bit Versions

There are three user mode debuggers available in the Debugging Tools for Windows package—NTSD, CDB, and WinDbg—and one kernel mode debugger (kd). Although these debuggers are three separate tools, it is important to understand that they all rely on the same core debugger engine. The most significant difference between the debuggers is that WinDbg has a graphical user interface (GUI) component, making it easier to work with when doing source level debugging. In contrast, NTSD and CDB are purely console-based debuggers. The snippets of debugger conversation that will be outlined in the book are all captured using NTSD.

After choosing the flavor of the debugger (32-bit or 64-bit), the installation process for Debugging Tools for Windows is straightforward and the default installation options are typically sufficient. The default installation path is

%programfiles%\Debugging Tools for Windows

here are several versions available for download. I have used version 6.8.4.0.

Working and Debugging with .Net Framework 2.0

.Net 2.0 SDK Path: (%programfiles\Microsoft.net\SDK)

SOS (General debugging extension for .NET applications)

Download URL: Part of .NET SDK

Location: %windir%\microsoft.net\<architecture>\<version>\sos.dll

Architecture can be either 32-bit Framework or 64-bit Framework, and the version represents the version of the .NET framework you are targeting. SOS is a debugger extension used to debug .NET applications using the native debuggers. It provides a truly amazing set of commands that enables developers to delve deep into the CLR and help troubleshoot pesky application bugs. Among other things, there are commands that enable you to see the finalization queues, managed heaps, managed threads, setting managed code breakpoints, seeing exceptions, and much more. Throughout the
course of the book, the SOS debugger extension will be used heavily to investigate complex application bugs.

SOSEX - SOS Extended (General debugging extension for .NET applications)

Download URL: www.stevestechspot.com/downloads/sosex_32.zip or www.stevestechspot.com/downloads/sosex_64.zip

SOSEX is another debugger extension targeted at the native debuggers and managed code debugging. It was developed by Steve Johnson and is available as a free download. SOSEX adds a set of powerful debugging commands to your arsenal. Examples of such commands include deadlock detection, generational garbage collection commands, and more powerful breakpoint commands.

CLR Profiler (Memory Allocation Profiler)

Download URL: www.microsoft.com/downloads/details.aspx?FamilyId=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en

The CLR Profiler is an invaluable tool when it comes to troubleshooting memoryrelated issues in .NET applications. It provides features such as

  • Heap statistics (including allocation graphs)
  • Garbage Collection Statistics
  • Garbage Collector Handle Statistics (including allocation graphs)
  • Garbage Collection Generation Sizes
  • Profiling Statistics


Reflector for .NET (.NET assembly analyzer and disassembler)

Download URL: www.aisto.com/roeder/dotnet/Download.aspx?File=Reflector

Reflector for .NET is a .NET assembly explorer tool that includes a powerful disassembler that can reproduce the code from the MSIL (Microsoft Intermediate Language) to a higher level language of choice. The language choices are C#, Visual Basic, Delphi, Managed C++, and Chrome. Additionally, it includes an extensibility model in the form of an add-in API. There are many add-ins available ranging from a code review add-in to a code metrics add-in.

PowerDbg (Debugger tool)

Download URL: www.codeplex.com/powerdbg

PowerDbg is a library developed by Roberto Farah that allows you to control the native debuggers via Powershell (requires 1.0). It is a super useful tool when you want to control the execution of the debuggers using the command line. The PowerDbg script returns information to the user in a neat and easily digestible fashion. The great thing about PowerDbg is that it is easily extensible and enables calling and formatting your favorite commands (or a set of commands in common debug scenarios). To utilize PowerDbg, the easiest way is to initialize it in the Powershell profile.

windir%\System32\WindowsPowerShell\v1.0\profile.ps1

Simply copy the PowerDbg script into that file and reopen a Powershell command window. You can now utilize the PowerDbg commands.

 

Managed Debugging Assistants (General CLR Debugging)

Download URL: Part of the CLR

Managed Debugging Assistants (MDAs) is not a standalone tool per se; rather, it is a component of the CLR that provides invaluable information when running and debugging .NET applications. If you are familiar with Application Verifier for native code, MDAs serve a very similar purpose. Through elaborate instrumentation of the runtime, common programming mistakes can be identified at runtime and subsequently fixed prior to shipping the application.

blog comments powered by Disqus

Posts By Month