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 (7)
  1. Shahar Prish says:

    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.

  2. Alik Levin says:

    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 production

    alikl

  3. alik levin's says:

    My answer is "no" . I am working on solution where there is no Windows Active Directory Domain so we

  4. alik levin's says:

    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of

  5. patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of

  6. Alik Levin's says:

        In my previous post -  Best ASP.NET Performance Winner For Data Binding – Hands

  7. Alik Levin's says:

    Field experience proves – the earlier performance is tackled in development lifecycle the better results

Comments are closed.

Skip to main content