Share via


Use Sysinternals DebugView To Diagnose The Application

"Unspecified error", "Catastrophic failure", "Object reference not set to an instance of an object" and other "self explanatory" errors promise no easy debugging. Good instrumentation of the application  to the rescue! The techniques described in the paper explores on very often overlooked healthmonitoring feature of ASP.NET 2.0. It supports few providers - mechanisms that collect and log the events emitted by the application:

  • SimpleMailWebEventProvider. This provider sends e-mail for event notifications.
  • TemplatedMailWebEventProvider. This provider uses templates to define and format e-mail messages sent for event notifications.
  • SqlWebEventProvider. This provider logs event details to a SQL Server database. If you use this provider, you should encrypt the connection string in your Web.config file by using the Aspnet_regiis.exe tool.
  • EventLogWebEventProvider. This provider logs events to the Windows application event log.
  • TraceWebEventProvider. This provider logs events as ASP.NET trace messages.
  • WmiWebEventProvider. This provider maps ASP.NET health monitoring events to Windows Management Instrumentation (WMI) events.

Nothing is to log into file or to show interactively though.

Here is another way for quick and dirty understanding what happened in the app (assuming instrumentation is in place). Instrumentation mechanism is my old friend System.Diagnostics.Debug.WriteLine(string message) . This command emits messages to OutputDebugString. The best tool that collects and shows the messages that I found so far is Sysinternal's Debugview.

The following code:

    protected void Page_Load(object sender, EventArgs e)
{
Trace.WriteLine("Loading the page");

    }

Would interactively look like this:

image

DebugView also offers logging the events into file - very handy.

 

While healthmonitoring is great to log stuff for later analyzing, tracing with DebugView is great for interactive debugging. I can think of some wrapper class that is used by the application to log the messages, and the implementation uses both healthmonitoring custom events and Debug.WriteLine. Both then rely on the web.config stuff.

 

Enjoy and happy debugging, tracing, instrumentation, and other veggies.

Comments

  • Anonymous
    July 16, 2007
    Note that my team has noticed several cases where using this tool caused hangs and crashes.This may be due to very large volumes of logging our server does - I am not sure - it has been a while since we used it.
  • Anonymous
    July 16, 2007
    Thanks, Shahar!I presume your comment is related to DebugView and not HealthMonitoring. I think i can leave with few crashes when debugging the app, all in all it is unusual process and the tool never runs all the time while the app in productionalikl
  • Anonymous
    August 01, 2007
    My answer is "no" . I am working on solution where there is no Windows Active Directory Domain so we
  • Anonymous
    January 20, 2008
    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of
  • Anonymous
    January 20, 2008
    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of
  • Anonymous
    July 31, 2008
        In my previous post -  Best ASP.NET Performance Winner For Data Binding - Hands
  • Anonymous
    November 01, 2008
    Field experience proves - the earlier performance is tackled in development lifecycle the better results