Debug Analyzer.NET - Debug Analyzer

Video Tutorial

Sukesh — Sun, 02 Jan 2011 04:13:00 -0500

Let us see different features in action in 5 min to fame style screencast...!

[vimeo:18995935]

How Learn Mode Works?

Sukesh — Sun, 02 Jan 2011 03:13:00 -0500

One of the core idea behind Debug Analyzer.NET is to aid in learning Debugging and also about the issues it detects.

Learn mode is a way for the analysis results to provide articles or other resource links which would help in understanding the issue better and also get guidance on how to avoid such issues in future.
Let us see how it looks like in a sample report.

The icon is a clickable link to resource article related to the issue. In this case it's the result of the following code in the analysis plug

WriteRecommendation(ResultSeverity.Error,
        "You have hit a performance bottle-neck related to Throttling [LM60001] " +
        (capacity == 16 ? " (due to very low default value on .NET 3.0)" : ""),
        "Please change the values of maxConcurrentCalls as per suggestion");

What are the different formats for Learn Mode articles ?

Learn Mode Articles - [LM<learnId>] eg. [LM50000] 
Microsoft KB - [KB<articleId>] eg. [KB123456] 
Microsoft Bulletins - [<bulletinId>] eg. [MS10-049]

How to get the list of Learn Mode Articles?

http://go.debuganalyzer.net

How Instant Analyzer works?

Sukesh — Sun, 02 Jan 2011 02:13:00 -0500

Instant Analyzer is more like SQL Query Analyzer, you write your analysis and hit F5 ("Compile & Execute") and it shows the results in the window below.
You can also save and load snippets, which are saved and kept under the 'snippets' folder. The 2nd icon for loading and 3rd icon for saving.

The following things happen when you hit F5 or "Compile & Execute"

Complete Analysis Plug source is generated by merging the source in the Code Editor below
The Analysis Plug is compiled (C# for now) to generate an in-memory Analysis Plug (assembly)
Plug Framework evaluates the Analysis Plug to get the Attributes
In-memory Plug is then instantiated and Invoked by the Debug Analyzer Engine
Debug Analyzer Engine invokes the Data Access Component for the relevant Data
Uses the Debugger to get the required data from memory dump requested by the Plug
Executes the Entry-point function of the Plug and generates the HTML report content
Debug Analyzer Engine gives back the HTML report content
Report window at the bottom, shows the HTML report content

Below screenshot shows powerful reporting capability with Graph to display Top 5 .NET Heaps details.

Below screenshot shows powerful Analysis capabilities using .NET Lambda expression syntax

The above snippets are already included in the download.

VB.NET support and 'Compile and Publish' option coming soon...
'Compile and Publish' option would allow you to convert snippet into Analysis Plug directly with the click of a button.

How Interactive Debugging Works?

Sukesh — Sun, 02 Jan 2011 02:13:00 -0500

Interactive Debugging feature provides a way for you to manually debug the memory dumps like you do normally. It also provides a way to save the output in RTF format so that you can use it for reference later.

The main benefit of Interactive Debugging is that it enables you to create .NET based commands, equivalent to Debugger Extension commands called 'Command Plugs'.
This feature is still work-in-progress so currently this feature supports only basic debugger commands.

More features in the pipeline... hold your thoughts!

Frequently Asked Questions!

Sukesh — Sat, 01 Jan 2011 03:13:00 -0500

I have addressed few questions below, but if you have any other questions or concerns, feel free to ask through comments.

Q. If I throw a Kitchen sink at Debug Analyzer.NET, will it analyze it for me?

Kitchen sink is not supported at this time.

Q. Can we use Debug Analyzer.NET to do live debug?

Debug Analyzer.NET is a memory dump analysis tool and does not support Live debugging. It's a non-technical decision since you already have tools like Visual Studio, Windbg etc available for that.

Q. Can we use Debug Analyzer.NET for debugging native memory dumps?

Current version of Debug Analyzer.NET supports analysis for .NET and few related commands from native world under Analyzer.DBG. Support for Native scenarios will be provided as and when required. This would be more to help the managed debugging rather than full fledged native support for now.

Q. What versions of CLR are supported by Debug Analyzer.NET?

Current version of Debug Analyzer.NET supports analysis for CLR v2 (and 3.x). CLR v4 support is coming soon after the initial release. Silverlight support is also planned.

Q. Will Debug Analyser.NET support CLR 1.x memory dumps?

There are no plans to support .NET 1.x since its usage is very low and not worth my personal time.

Q. If I write Analysis Plug, how do I get credit for the usage?

Analysis Reporting Framework uses Plug 'Assembly Attribute' called 'Company' to show Author name in the Plug footer. You can add your name or website to show up as Author there (no HTML).

Q. Why is Debug Analyzer.NET current release numbered as V2?

There was a V1 version of Debug Analyzer.NET which was released to showcase the idea of how analysis can be done using Plug Framework. Current version is improved with a redesign of the architecture, implementing a Provider Model and Data Access Components. Also several features were added, one of them being Instant Analysis.

Q. After completion of Debug Analyzer.NET v2, then what?

I have a complete roadmap prepared for v3 and would love to continue working on it. I will be publishing the roadmap sometime in the future.

Q. Does Debug Analyzer.NET contain bugs?

You bet, it would have bugs since it's built by human (yours truly). I have also provided Diagnostic Tracing, configured through config file to get more information about the bugs, as and when it happens.

Q. What is the easy way to learn to write Analysis Plugs?

I'll be blogging more about analysis with samples as snippets which you can use from Instant Analyzer. Also all the built-in Analysis Plugs source would be shared through Codeplex project for your learning pleasure. Since the flow of the Analysis is same as what we do manually, you can learn debugging in Windbg with sos/psscor if you know how to write Analysis and vice versa.

How to Run Analysis?

Sukesh — Sat, 01 Jan 2011 02:13:00 -0500

One of the core features of Debug Analyzer.NET is to run Analysis on the memory dumps and provide a friendly report to show you the details in dumps, issues detected and recommendations for resolving those issues. This is accomplished by using a modular approach using Analysis Plugs. The Analysis Plugs are then grouped into what are called "Analysis Templates" according to the scenarios or issues we are troubleshooting.

Let us see how the "Analysis Templates" are shown on the left side of the main screen.

How do you Run Analysis?
So when you want to run analysis, you need to select a memory dump and select one of these "Analysis Templates" and click on "Run Analysis".
Each sub element shown under the Template Name (highlighted in blue) are individual Analysis Plugs.
Please see the article titled "Hello World Analysis Plug" on the right for learning to write your Analysis Plugs.

How do you create Analysis Template?
From the top menu click Tools > Analysis Templates. You can get the following screen where you can edit your Templates.

How Application Update works?

Sukesh — Sat, 01 Jan 2011 02:13:00 -0500

Let's see step-by-step how the Application Update works with screenshots. Keep in mind at this time you need to manually trigger the update process.
And this would be the case during the Beta timeframe.

Use Help > Check for Updates... option

Notify about the newer version availability

Downloading the Updates

Updates downloaded and ready to be applied.

Updates installed and ready to launch the newer version

Verify the Version number from Help > About

Architecture & Design

Sukesh — Sat, 01 Jan 2011 01:13:00 -0500

From my experience as a developer I have seen a lot of great applications from architecture perpsective. One of those things which is often left out and comes as last is the application extensibility and developer experience. This leads to either complicated configuration settings or a huge learning curve to accomplish simplest of things.

When I started building this application, I had few guidelines and I worked backwards in many things to make developing experience more easier (still learning to do more though...).
One of the best things to happen in Developer world is the intellisense support. It is more like copy/paste of the developer world and I wanted to make sure I use that in the best possible ways.

Design Thoughts

Write Analysis just once and it works for both x86 and x64
Debug Analyzer built-in framework abstracts away the Data Access, so your Analysis just works without changes on x86 & x64 targets since it's written against the Object Model and have no dependency on processor architecture of the memory dumps.
Plug Framework
This framework allows the flexibility of dropping a DLL in designated folder and the application consuming it. Makes it easier for writing analysis with little or no learning curve. This framework is used in all core features like Analysis Plug, Command Plug, Visualizer Plug etc...
Analysis Workflow
Enabling developers to learn debugging memory dumps was one of the requirements and this is achieved by having the flow of analysis plugs follow almost the same pattern of how you do manually using windbg and sos/psscor. This enables you to do both, write analysis if you know how to debug using windbg + sos/psscor and vice versa.
Object Model
Build a Object Model heirarchy which is consistent and easy to discover in a heirarchical manner. This is implemented with the Analyzer Object Model heirarchy. It also uses intellisense to show you the entire heirarchy and smooth flow.
Extensibility with Abstraction layers
Designed as a tiered application with extensibility to replace components through config using abstraction layers. Analysis Engine can be called by passing simple parameters. Data Access Components can be replaced by just changing it in config file, specially if you want to change the data source.
API is contained in single DLL (Debug.Analyzer.API)
Whatever you do, you set reference only to a single DLL, whether it's to write Plugs, Tracing, DAC or anything else.
Reporting Framework
Reporting Framework handles look and feel completely using XML/XSL. This was done to make sure there is a structured way for reporting and also enables to change the look and feel of the reports without rewriting or recompiling the Plugs.
Reduced footprint.
Since entire Windows Debugging Tools is a larger download, Debug Analyzer uses MSDN documented COM interfaces to interact with the memory dumps and use sos/psscor to extract data relevant to CLR. Moving to .NET Framework 4.0 was also done to reduce the number of prerequisites!
Better resources to educate.
Learn mode plays a major role in educating developers on what the issue was and how it can be avoided by explaining the reasons in detail for the issue. Often times, analysis results comes with complicated terminologies assuming everyone are aware of the said terminologies. Learn option enables developers to get more information about the said problem and gain knowledge to make sure the mistakes are not repeated.

Simplistic looks at the different component layers

How it works!
Here is the flow of events which happens when you click 'Run Analysis'

Calls Debug Analyzer Engine with the 'Analysis Template' name and the memory dump file details
The Engine loads all the Analysis Plugs which are part of the specific Template
Instantiates each individual Plug and run the code using the entry point 'RunAnalysis'
On 1st use Plug Framework invokes the Input Provider which is part of Provider Framework
Provider Framework does lookup in the config and loads/instantiates the relevant Data Access Component
Provider Framework also does caching inside the Object Model on 1st load of the Collections to make the analysis faster
Data Access Component has the complete logic of how the the data is extracted out of the Data Source which are memory dumps (for now)
Reporting Framework captures the output generated in XML form and returns the Analysis fragment for each Plug
After all the Plugs have returned, the individual fragments are used by Reporting Framework with built-in XSL to generate output HTML
Writes the output to Reports folder and Shows the generated report in the main application.

There were few challenges as well which are explained below.

Challenge #1 - Textual output from Debugger and Extensions
Debugger Engine (dbgeng) works great for manually debugging and analyzing issues but when you want to build automation for debugging, textual output from the debugger becomes difficult to use. None of the debugger extensions provide alternate output which can be consumed for automation easily.

This became a challenge specially since this is also true with Debugger extensions like sos/psscor used for .NET debugging. Writing an extension with all the features does not make too much sense, since that would also involve keeping things upto date with the changes in CLR etc. So the best alternative was to use the debugger output from sos/psscor and parse the string output.

This introduces a question, what happens when the debugger extension changes the output format. Do I need to change my analysis as well? The answer to that was to build a Data Access Component abstraction layer so that Analysis is written against the Object Model and the underlying data can be changed without breaking them. This also helps in changing from SOS strings as it is used today to probably use ICorDebug later, all these done without breaking the existing Analysis already written.

Challenge #2 - Debugger (dbgeng) redistribution and the version in the OS
Debugger Engine which provides all the debugger functionality is contained in a DLL called dbgeng. This is distributed with the OS but not regularly updated. The latest updates come with the 'Windows Debugging Tools' package. Since the size of this package is larger, it becomes a larger download dependency for a simple application like Debug Analyzer.NET

Best choice was to use the version of the Debugger Engine available in the OS and use the COM based interface as documented on MSDN. This is implemented at the Data Access Component layer which is written in C++/CLI.

[Note: If you have any questions/concerns/feedback you can reach out to me through comments or Contact page ]