More on redirecting Diagnostics trace to ASP.NET

In my last post on ASP.NET tracing I showed you how you can redirect trace information from System.Diagnostics.Trace.Write* methods to the ASP.NET in-page trace block.

I have some extra information on this topic.

First of all, like any other listener you can apply a filter to the WebPageTraceListener and pick up just the traces that you like. You can specify a SourceFilter or an EventTypeFilter, to filter on trace source or on the level of trace information being sent.


  <trace autoflush=true>


      <add name=WebPageTraceListener traceOutputOptions=ThreadId

        type=System.Web.WebPageTraceListener, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a >

        <filter type=System.Diagnostics.EventTypeFilter






Now you will only see the trace information of level Critical, Error and Warning, but not Information or Verbose. It is the filter of this listener that will block the values from actually reaching the listeners target (i.e. the ASP.NET page). The initializeData takes a value of System.Diagnostics.SourceLevels enumeration.

Second, you can use other methods than Trace.Write(If) and WriteLine(If) to send out diagnostics trace information. The other methods are TraceError, TraceWarning and TraceInformation. If you use either of these, you cannot specify the category of the trace. But interesting things happen in the ASP.NET trace output anyway. Consider this code fragment:

  Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

    System.Diagnostics.Trace.TraceError(“Output of TraceError”)

    System.Diagnostics.Trace.TraceWarning(“Output of TraceWarning”)

    System.Diagnostics.Trace.TraceInformation(“Output of TraceInformation”)

  End Sub

The output of this trace looks like this:

Remember to check your EventTypeFilter value if one or more of these values do not show up.

Notice how the category is filled with the process hosting the ASP.NET runtime and the prefix of Event 0. And, the tracing with error or warning use TraceContext.Warn instead of Write, to make the line light up in red. Normally you can include extra information in your trace messages by specifying a set of OR’d TraceOptions in the traceOutputOptions attribute of a listener (check the first configuration fragment in this post to see where you specify this). The footer of the message will automatically include any information you asked for. This can any combination of the following:

  • Callstack: current call stack as in Environment.StackTrace

  • Current date and time

  • Logical operation stack: value of CorrelationManager.LogicalOperationStack

  • Process ID

  • Thread ID

  • Timestamp: returns the value of Stopwatch.GetTimeStamp()

Unfortunately the WebPageTraceListener overrides all Write methods and these overrides do not include a footer (via a call to WriteFooter). Any TraceOutputOptions that you might have set on the listener are not used. All other listeners that do use these options. I guess it has been removed from the WebPageTraceListener to keep the trace records short. 

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s