by IIS Team
In ASP.Net today, developers can add trace events to ASPX pages using Trace.Write()& Trace.Warn() calls in the script sections of their page. Typically, you use these traces to debug an application that does not work as expected.
These events appear when you enable tracing for the page (set <%@ Page Trace="True" %>). You can only view these events by default when browsing the application from the server (i.e. Localhost), or when you enable Application Tracing to keep the last given number of sessions.
However, the problems with this process are:
- These traces are not persisted, so if the process goes away, so do your traces
- These traces are collected regardless of the status code for the request – i.e. if it succeeds or fails, you get traces
- These traces are viewed completely separately from any other infrastructure traces provided by IIS 7.0 and above or ASP.net
In IIS 7.0 and above, you can collect these traces in Failed Request Tracing or ETW tracing in addition to viewing them normally. And, you can view these traces in conjunction with IIS and ASP.net infrastructure traces.
Tasks illustrated in this walkthrough include:
- Configuring failed-request tracing to capture ASP.net Page Trace.Write and Warn calls
- Generating the failure condition and viewing the resulting trace capture, finding the Trace.Write and Trace.Warn calls
The following steps include the prerequisites necessary for completing the tasks in this article.
Step 1 : Installing IIS 7.0 or Above
IIS 7.0 or above must first be installed. To check if IIS is installed, browse to http://localhost. If you see the "under construction" page, then IIS is installed. If IIS is not installed, refer to the "Installing IIS 7.0 and Above" guide for installation instructions.
Make sure to install the following IIS Components:
- ASP (under World Wide Web Services => Application Development Features => ASP)
- Tracing (under World Wide Web Services => Health & Diagnostics => Tracing)
Step 2 : Log In as Administrator
Make sure to login to the administrator account or in the Administrators group.
Being in the Administrators group does not grant you complete administrator privileges by default. You must run many applications as Administrator. Right-click the application icon and choose "Run as Administrator".
Step 3 : Make a Backup
You must make a backup of the configuration before executing tasks in this article. Run the following:
Click the Start button -> All Programs -> Accessories -> (r-click)Command Prompt -> Run as Administrator.
Execute the following command in that command prompt:
%windir%\system32\inetsrv\appcmd add backup
Adding a New Trace.Write() & Trace.Warn() Call to a Sample ASPX Page
In this task, you add Trace.Write() & Warn() calls to a sample aspx page and view the resulting traces in your browser.
- Use the Administrator command prompt and navigate to your
Use your editor of choice and create an aspx page called trace.aspx, putting the following code in the page:
<%@ Page language="C#" trace="true" %> <% Trace.Write("Hey, there"); Trace.Warn("Doh, a warning"); Response.Write("hello, world"); %>
Browse to http://localhost/trace.aspx. You see the following:
Notice the events above: "Hey, there" and "Doh, a warning".
We have just added a new event to our page. Now see if we can get Failed Request Tracing to capture it.
Adding a New Trace.Write() & Trace.Warn() call to a Sample ASPX Page
The page is now instrumented with Trace.Write & Trace.Warn calls. Configure Failed Request Tracing to capture the ASPX page Trace.Write() & Warn() calls.
For this scenario, we must use the ASP.Net provider's Page area, with Trace.Write calls corresponding to the Verbose verbosity level, and Trace.Warn() calls corresponding to the Warning verbosity level. Setting the verbosity level to Verbose gets both.
Step 1 : Enabling Failed Request Tracing for Your Site
Failure Request Tracing first must be enabled for the site. Steps to enable are found in the HOWTO-FailureRequestTracing Walk Through, Task 1.
Step 2 : Creating a Failed Request Tracing Rule to Capture the Trace.Write() & Warn() Events
From the Administrator command prompt, type start inetmgr. In the Connections panel, expand the machine name, then Sites folder, then click the Default Web Site. Under IIS, double-click Failed Request Tracing Rules.
In the Actions pane, click Add…. to launch the Add Failed Request Tracing Rule wizard. On the Specify Content to Trace page, click the ASP.NET (*.aspx) option for what to trace and click Next.
In the Define Trace Conditions screen, check the Status Codes check box and enter "200" as the status code to trace.
Click Next. The Select Trace Providers page appears. Select the ASPNET check box and the Page check box under "Areas" (uncheck all other areas that are checked except Page) Under Verbosity, select Verbose.
Click Finish. You see the following definition for the Default Web Site:
Step 3 : Test and View
In this step, we generate a request for http://localhost/trace.aspx and then check the Failed Request Tracing log file to see the trace events.
To verify that it worked:
- Open an Administrator-elevated new Internet Explorer window.
- Type in the address http://localhost/trace.aspx.
- We generated the traced request, so open an Administrator-elevated Internet Explorer window, enter CTRL-O to open a file, and navigate to inetpub\logs\FailedReqLogFiles\W3SVC1 folder. In the HTML Files dropdown list, select All Files.
Select the most recent FR######.xml file. You see the following:
The events display above in the trace log. Notice that the event "Doh, a warning"'s SubType Name is "AspNetPageTraceWarnEvent" - that is the Trace.Warn() event.
All Trace.Write() calls are very high verbosity (verbosity = "Verbose"); hence, the reason for the <Level>5</Level>, while all Trace.Warn() calls are logged as Warnings.
There are many other "AspNetPageTraceWriteEvent" events logged. This is because all the other entries in the trace table, like Begin PreInit, etc., are all logged through the same infrastructure as well.
We finished adding trace messages to the ASPX page. We configured IIS to capture those traces, when enabled, in the Failed Request Trace Logfile. Remember that these trace entries are only logged to the trace logs if the page's trace="true" directive is set, and the ASP.NET provider with the "Page" area is defined when tracing (either using ETW or Failed Request Tracing).