Debugging, Tracing and
Instrumentation in .NET and ASP.NET (14 FAQ)
what's the agenda?
What is Instrumentation?
What is debugging and tracing?
How can we
implement debugging and tracing in ASP.NET ?
How do we view the
results of debug and trace?
So can we see a quick sample of how tracing information can be viewed?
What if we want to
enable tracing in all pages?
Is it possible to do silent tracing, rather than displaying on the browser?
How do I persist the
There is too much noise can we only see information which we need?
All the above methodologies are for web, how can we do tracing for windows?
Can we emit different types of trace events like critical, warning, error etc?
Can we control
what kind of information can be routed?
How can switch off
It would great if we can
Diagnosing a software application is an art and this art has to be more skillful
when you go on production. In development environment you have the complete VS IDE tool so the diagnosing
becomes much easier. On production environment as a best practice you do not
install visual studio IDE. So on production it's like fighting with the lion
without a knife.
This article has a three point agenda.
. We will first start with understanding some basic vocabularies like debug,
trace and instrumentation.
. Once we understand the vocabularies we will see how to use the trace attribute
to tracing in ASP.NET. We will also understand some drawbacks of the same.
. We will then try to remove those drawbacks using the full tracing framework
which comes as a part of "system.diagnostic" namespace. In tracing framework we
will try to understand trace object , switches and listeners.
You can watch my .NET interview questions videos on various sections like WCF,
Silver light, LINQ, WPF, Design patterns, Entity framework etc.
Debugging application is not just
about pressing F 10 or F 11 and watching "add watch windows" using visual studio
IDE. Debugging becomes pretty complex on production environments where the
project is deployed in a release mode and you need to figure out till what point
the code ran and when did it crash. The worst part is you are enjoying your
sleep at home and suddenly someone calls up and says, "Hey! the application
crashed in production".
If your application is well planned with proper instrumentation you can just say
the person to view the event viewer or a log file for further details and you
can give the solution on the phone itself.
So defining instrumentation in short, it's the ability of the application to
monitor execution path at critical points to do debugging and measure
We would like to enable application instrumentation in two situations while you
are doing development and while your application is in production. When you
monitor application execution and performance in development stage is termed as
"Debugging" and when you do in deployed environment it's termed as 'Tracing'.
Debugging and tracing can be
implemented by importing 'System.Diagnostic' namespace and by calling 'Debug'
and 'Trace' methods as shown in the below code. In the below code we are
tracking critical execution points like page load and button click.
protected void Page_Load(object sender, EventArgs e)
Debug.Write("Debug :- The page is loaded\n");
Trace.Write("Trace :- The page is loaded\n");
protected void Button1_Click(object sender, EventArgs e)
Debug.Write("Debug :- Button is clicked\n");
Trace.Write("Trace :- Button is clicked\n");
As said previously debug is meant for enabling instrumentation in development
phase while tracing helps during execution. During development VS IDE tool is
the best medium of viewing debug information and during execution the mediums
can be a browser, event viewers, file system etc.
In order to see debug information execute the project, click on debug, windows
and click on output menu as shown in the below figure.
You should be able to see the output
information in output windows as shown in the below figure.
As debug code is not shipped in
production you will not be able to see the debug information while your
application is go live. As said previously tracing information is seen when you
execute the project in production mode or go live mode. Tracing information can
be viewed by on various mediums:-
. By the user interface ( Web browser or the windows UI)
. Event viewer
. Log file, format can be XML, CSV etc.
. In ASP.NET you can also view by using Trace.axd
A quick and dirty way of seeing
tracing information is by going to the ASPX front code and put trace=true in the
<%@ Page Language="C#" AutoEventWireup="true" trace="true"
CodeBehind="Default.aspx.cs" Inherits="WebTracing._Default" %>
Once you have done the same you should be able to see tracing information as
shown in the below figure. With trace enabled as true it also displays lot of
other things like different page events , session data , hidden field data ,
http headers etc. I have circled the custom information which we have written
using the 'Trace' object.
If you want to enable tracing in all pages, you need to
enable trace in the 'web.config' file as shown in the below code snippet.
In actual production it will not be a
good idea to enable the trace using the above two methodologies as the end user
can view your tracing information on the browser. So the next logical question
is how we silently trace the same.
In order to background silent tracing we need to go to the web.config file and
in the trace tag enter pageoutput=false. By setting "pageoutput" to false we say
the trace engines do not send messages to browser and collect them in memory.
This in memory stored instrumentation data can be viewed using Trace.axd by
http://localhost:2281/Trace.axd . Below is a sample screen shot which
shows how the data looks. If you click on the view details you can see the
When we instrument using debug attribute either using page or AXD extension they
are not persisted. In other words they are displayed on the browser temporarily.
Most of the times we would like to persist the information in a file, event
viewer etc so that we can later see the history for proper diagnosis.
We need to enable the
'writetoDiagnosticsTrace' attribute to true. When this attribute is set to true
the information is sent to a listener.
You can then define various types of listeners like text file listener, event
viewer etc. Below is a sample code snippet of how the listeners actually look.
So the ASP.NET tracing engine will emit diagnosis information which will be then
caught and routed to the proper source by the listener.
initializeData="c:\outfile.txt" traceOutputOptions="ProcessId, DateTime"/>
Below is a simple snapshot of how instrumented data is captured.
When we use the trace attribute it
emits out all the events of the page. Sometimes these events can hinder your
If you want to eliminate all ASP.NET
events and just concentrate on your message then we need to add a source. We
need to then write the messages on the source and the source will redirect the
same to the trace listeners.
In order to define a source go to
your web.config and in the "system.diagnostics' tag enter the "source' tag as
shown in the below code snippet. In the below code snippet we have defined the
source name as "myTraceSource". Inside the source we can define various
Below is a complete sample code
snippet with listeners defined inside the source.
In order to send messages to the trace source using C# code first we need to
import namespace "System.Diagnostics" as shown in the below code snippet.
Once the namespace is imported we can
then send messages on any event by creating the "TraceSource" object and calling
"TraceEvent" as shown in the below code snippet.
TraceSource obj = new TraceSource("myTraceSource");
obj.TraceEvent(TraceEventType.Error, 0, "This is a error message");
It's the same way define the source
and listeners in your app.config file, create the tracesource object and call
traceevent method to write the same to the listeners.
We would like to emit different kind of messages from the application like
critical messages, error message or just information. The types of messages can
be defined by using "TraceEventType" enum as shown in the below code snippet.
obj.TraceEvent(TraceEventType.Critical, 0, "This is a critical message");
obj.TraceEvent(TraceEventType.Warning, 0, "This is a simple warning message");
obj.TraceEvent(TraceEventType.Error, 0, "This is a error message");
obj.TraceEvent(TraceEventType.Information, 0, "Simple information message");
obj.TraceEvent(TraceEventType.Verbose, 0, "Detail Verbose message");
Sometime we would like to control the
kind of diagnosis information we see. This can be achieved by using the switch
tag in config file.
You can define various values
depending on what kind of diagnose information you want to record.
|| Type of message
|Critical = 1
|| Fatal error or application crash.
|Error = 2
|| Recoverable error.
|Warning = 4
|| Noncritical problem.
|Information = 8
|| Informational message.
|Verbose = 16
|| Debugging trace.
|Start = 256
|| Starting of a logical operation.
|Suspend = 1024
|| Suspension of a logical operation.
|Stop = 512
|| Stopping of a logical operation.
|Resume = 2048
||Resumption of a logical operation.
|Transfer = 4096
||Changing of correlation identity.
You can then attach the switch to the source.
Set the switch value to zero.
Summarizing ASP.Net or windows
application emits tracing information to the trace source; these messages can be
controlled by switches and sent to various sources (file, event viewer, xml etc)
which are defined using trace listeners. Below figure summarizes the complete
tracing framework visually.
Tracing in .NET and Implementing Your Own Trace Listeners
BCL Team Blog A Tracing Primer - Part I [Mike Rousos]
Cutting Edge A Provider-Based Service for ASP.NET Tracing
How to Configure
Viewing diagnostics trace info in an ASP.NET Website - Alex Thissen Weblog Build
Integrating ASP.NET Tracing with System.Diagnostics Tracing
With the article we have also
provided the source. The source code demonstrates:-
. Trace attribute
. Enabling trace using web.config file
. Tracing in windows application
Trace listeners, switch and trace