Daniel Vasquez Lopez's Blog : Rewrite

How to consume ETW events from C#

Daniel Vasquez Lopez — Tue, 03 Feb 2009 04:30:00 GMT

In my previous post I explained how to collect ETW events from URL Rewrite (or any other IIS provider) and then display those structured events in the Event Viewer. Now I want to show you how to collect ETW events using C#.

The .NET Framework 3.5 provides a new namespace System.Diagnostics.Eventing.Reader where you can find useful classes for publishing ETW events, but doesn’t provide a mechanism for consuming, so I had to write a class EventTraceWatcher for simplify things.

I want to use this class for tracking, in real time, all the URL Rewrite Events.

Setup Event Trace Session

The first thing to do is to setup the session, open “Reliability and Performance Monitor”, go to Event Trace Sessions and add a new Data Collector Set named “Rewrite”; my previous post has more detailed steps, once you create the collector set, go to its properties and add the provider “IIS: WWW Server” and the Keyword 0x400 (Rewrite) and set the Level to 5. Here is how it should be:

Use stream mode “Real Time”

By default the Data Collector Set will write the collected events in the file system. Change it from File to “Real Time”. Your .NET Application will be listening those real time events. Open the data collector properties and in the Trace Session tab change this setting.

Make sure to start the Rewrite Collector once you are finish with this settings.

EventTraceWatcher class

The EventTraceWatcher class is very trivial to use, you need to provide the name of the Data Collector Set to it’s constructor (“Rewrite” in our example), hook the event “EventArrived” in your code and then just set the property Enabled to true to start the asynchronous processing of the ETW Events.

using System;
using Microsoft.Iis.Samples.Eventing;

class Program {
    static void Main() {
        try {
            new Program().Run();
        }
        catch (Exception ex) {
            Console.Error.WriteLine(ex);
        }
    }

    private void Run() {
        Guid RewriteProviderId = new Guid("0469abfa-1bb2-466a-b645-e3e15a02f38b");

        using (EventTraceWatcher watcher = new EventTraceWatcher("Rewrite")) {

            watcher.EventArrived += delegate(object sender, EventArrivedEventArgs e) {

                if (e.EventException != null) {
                    // Handle the exception
                    Console.Error.WriteLine(e.EventException);
                    Environment.Exit(-1);
                }

                // Process only URL Rewrite events
                if (e.ProviderId != RewriteProviderId) {
                    return;
                }

                // Dump the event name (e.g. URL_REWRITE_START, ABORT_REQUEST_ACTION, etc).
                Console.WriteLine("Event Name: " + e.EventName);

                // Dump properties (e.g. RewriteURL, Pattern, etc).
                foreach (var p in e.Properties) {
                    Console.WriteLine("\t" + p.Key + " -- " + p.Value);
                }
                Console.WriteLine();
            };

            // Start listening
            watcher.Enabled = true;

            // Listen events until user press <Enter>
            Console.WriteLine("Press <Enter> to exit");
            Console.ReadLine();
        }
    }
}

With this code you can write tools to help you to filter in real time information from IIS. Download the EventTraceWatcher class from:

http://code.msdn.microsoft.com/EventTraceWatcher

How to display URL Rewrite ETW Events in the Event Viewer

Daniel Vasquez Lopez — Mon, 26 Jan 2009 01:28:00 GMT

IIS Failed Request Tracing is a powerful way to troubleshoot Web Requests, it provides an easy way to track each execution step for one specific request. URL Rewrite Module provides several events that can be tracked using Failed Request Tracing, here is an article that explains how: http://learn.iis.net/page.aspx/467/using-failed-request-tracing-to-trace-rewrite-rules/

IIS Modules have the ability to publish ETW Events almost for free and URL Rewrite was not the exception and implemented this feature. There are many ways to listening for ETW Event, but one way that I found really easy is using the Event Viewer and the Reliability and Performance tools in Windows 2008 (and Vista).

I’m running Windows 2008, so let me show you how to listen the URL Rewrite ETW events using the Server Manager tool.

Be sure IIS Failed Request Tracing is enabled by following the article above.
Open Server Manager and navigate to Server Manager / Diagnostics / Reliability and Performance / Data Collector Sets / Event Trace Sessions
In the Action Pane select More Actions > New > Data Collector Set
Choose a Name and click Next
In the “Which event trace providers would you like to enable?” step, click Add (wait some seconds) and choose “IIS: WWW Server”:
Choose the property “Keywords(Any)” and click Edit. For URL Rewrite events, you need to choose Manual and type the value 0x400. You can optionally mix this value with any other flag available like IISSecurity or IISModule (0x200); if you select Automatic and the flag, you will see in the Manual text box the flag value. Click OK to close the Property dialog.
Now choose the property “Level” and click Edit, this time select Manual and type the number 5. Click OK and the Finish.
A new Event Trace Session has been created. You can click the Start button any time to start listening and recording all the URL Rewrite events.
By default, all the recorded data will be stored in the directory %LOCALAPPDATA%, to change this, select the session “URL Rewrite” and choose Properties from the contextual menu. There is a Directory and File tabs change your settings.

Let’s do a break. At this point you had configured Windows to start listening URL Rewrite events; those events will be recorded in a ETL file that can be processed by many tools like Log Parser and TraceRpt.exe. To display those event in the Event Viewer you need:

In the Server Manager tool, navigate to Server Manager / Diagnostics / Event Viewer / Application And Services Logs
Click the action Open Saved Log and choose the ETL file, if you didn't’ change the default settings, it should be at “%LOCALAPPDATA%\URL Rewrite.etl”. Click OK to close the “Open Saved Log” dialog.
Select the URL Rewrite log from the Saved Logs folder:
Now you will realized that the Event Viewer only has one part of the information available, the ETL file, it still needs to match that data to some other metadata stored in the WMI repository store in order to show you the formatted data.
Select the “URL Rewrite” log and click the action “Save Events As” and safe the log as “URL Rewrite Events.evtx” (note the new extension).
Once saved, open the new file using, again, the action “Open Saved Log”
Now you click any Event in the list. The General tab won’t show anything relevant, but the Details will:

I will have some conclusions later, I have to leave now. Hope you find it somehow useful.

Write your own UI Rewrite Template Extension!

Daniel Vasquez Lopez — Sun, 28 Sep 2008 06:21:00 GMT

The GoLive release of URL Rewrite Module is now available and has a lot of improvement thanks to the IIS Community feedback (and tons of internal brainstorm meetings!). A new feature is the ability to create Rewrite Rules by using Rewrite Templates, Rewrite Templates are UI extensions that help to simplify the creation of rules.

URL Rewrite Module includes 3 templates and more interesting, it allows you to add your own Rewrite Template.

Take a look to the following walkthrough if you haven’t play with Rewrite Templates:

http://learn.iis.net/page.aspx/497/user-friendly-url---rule-template/

I want to show you how easy is to write your own Rewrite Template extension, here is how this demo should look like:

As you know, iis.net has already some good articles that explain how to create an IIS Manager UI Module, so allow me to reuse the following article:

http://learn.iis.net/page.aspx/269/how-to-create-a-simple-iis-manager-module/

Follow the article above and once you are done with it, please do the following changes.

Add the assembly Microsoft.Web.Management.Rewrite.Client.dll to your C# project. If you can’t find the assembly reference in the GAC, download it from here.
Replace the code in DemoModule.cs by the following code that registers your extension in the URL Rewrite UI Module:

using System;
using Microsoft.Web.Management.Client;
using Microsoft.Web.Management.Iis.Rewrite.RewriteTemplates;
using Microsoft.Web.Management.Server;

namespace ExtensibilityDemo
{
internal sealed class DemoModule : Module
{
    protected override void Initialize(IServiceProvider serviceProvider, ModuleInfo moduleInfo)
    {
      base.Initialize(serviceProvider, moduleInfo);

      IExtensibilityManager extensibilityManager = (IExtensibilityManager)
        GetService(typeof(IExtensibilityManager));

      extensibilityManager.RegisterExtension(typeof(RewriteTemplateFeature),
        new DemoRewriteTemplateFeature(this));
    }
}
}

Add a new file named DemoRewriteTemplateFeature.cs and copy and paste following code:

Download the demo from here:

To install it, you will need to GAC the assembly RewriteExtensibilityDemo.dll and register the module in administration.config by adding the following entry under the moduleProviders section:

URL Rewrite for IIS 7.0 / Regular Expressions and Wildcards

Daniel Vasquez Lopez — Sat, 07 Jun 2008 01:20:00 GMT

Last week we shipped the first preview of URL Rewrite Module for IIS 7.0. If you are not familiar with URL Rewriting engines, please check out the walkthroughs:

http://learn.iis.net/page.aspx/460/using-url-rewrite-module/.

If you are you familiar with mod_rewrite, I’m pleased to let you know that we have a mod_rewrite rule importer feature to help you to leverage your rule-crafting knowledge:

http://learn.iis.net/page.aspx/470/importing-apache-modrewrite-rules/

URL Rewrite Module ships two matching engines, one for Regular Expressions (Perl 5 compatible/ECMAScript) and a simple one for wildcard matching. You can choose the engine you feel more comfortable with, I just want to give you some facts (some of them are silly but they are just a reminder):

1. Regex matching is more powerful, but expensive in terms of execution time.

2. Wildcard matching is cheaper than Regex and easy to understand.

3. Both engines are case-insensitive by default.

4. Case-sensitive matching has much better performance than case-insensitive.

5. Wildcard matching assumes “exact match”. For an expression like “blog”, it would match “blog” and only “blog”.

6. Regex matching assumes “partial match”. In this case, “blog” will match “blogger”, “demo/blog”. If you want an exact match you need to change the match expression to “^blog$”.

7. In Regex, “.” is reserved, it means “any character”, so “default.aspx$” will match “defaultXaspx” too. Escape it to “default\.aspx$’. Wildcards doesn’t have this behavior, the only reserved character is ‘*’.

8. To create a capture in Regex, use parenthesis.

9. Each ‘*’ in a wildcard expression creates a capture. For example, an expression like “*.*” would match “logo.jpg” and it will create 2 captures, “logo” and “jpg” (without the dot).

10. You can reference a capture by index. The index is 1-based, so in the previous example 1 means “logo” and 2 means “jpg”.

11. The index 0 means “the entire input”. In the previous example 0 means “logo.jpg”.

12. The syntax for back-reference a capture is {type:index} where type can be R for “Rule Back References” and “ C for “Condition Back References”. The index must be and integer equals or greater than zero.

Please give all the feedback you want, this is a technical preview so your feedback can definitely make a difference for the next release.

Install it from:

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x86)

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x64)

URL Rewrite Forum:

http://forums.iis.net/1152.aspx