"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:
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.