872 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 Figure 17.12 ASP.NET Trace Information Now you’re seeing the same basic results in this trace fi le as you saw on the actual page for ASP.NET. But what about the integration between ASP.NET and IIS 7.0? For that, we need to open up the scope of the information that we want to see in the failed request. To do that, we’ll create a new rule and select all tracing providers: 1. Using IIS Manager, navigate down to your target Web application. 2. Click Failed Request Tracing Rules and then click Open Feature in the Actions pane. 3. First, select the previous rule and then click the Remove link in the Actions pane. We’ll do this to keep things simple. 4. From the Actions pane, click the Add…link. 5. From the Specify Content to Trace page, select ASP.NET (*.aspx) and click Next. 6. From the Defi ne Trace Conditions page, check the Status Codes check box and enter 200 as the status code. 7. From the Select Trace Providers page, we won’t deselect anything. Thus, we’ll watch for everything. 8. Click Finish. 9. Using a browser, navigate back to the simpletrace.aspx page and then open the latest failed request log fi le. Toward the bottom of this Web page, you’ll fi nd the trace information as defi ned within the ASP.NET page (see Figure 17.12). Troubleshooting 101: Diagnostics in IIS 7.0 • Chapter 17 873 You should see an increase in the amount of information within the trace fi le. Although this is a bit “noisy,” you get a good idea of the amount of information found within the trace, and you see how the ASP.NET, IIS 7.0, and developer-defi ned tracing information is centralized into a single fi le. There is a known issue when trying to use the ASP.NET trace provider: It won’t show up in the list of trace providers when you create a new rule. Open %windir%\system32\inetsrv\confi g\applicationHost.confi g using Notepad and add the following to <traceProviderDefi nitions>: <traceProviderDefi nitions> other providers defi ned <add name=“ASPNET” guid=“{AFF081FE-0247-4275-9C4E-021F3DC1DA35}”> <areas> <add name=“Infrastructure” value=“1” /> <add name=“Module” value=“2” /> <add name=“Page” value=“4” /> <add name=“AppServices” value=“8” /> </areas> </add> </traceProviderDefi nitions> The issue noted previously is relevant to the initial version of Windows Vista. This issue will be resolved in the fi nal version of Windows Server 2008 and Windows Vista Service Pack 1 and the workaround will no longer be needed. Modify the XML The following XML is taken from the applicationHost.confi g fi le. It encapsulates all the changes we previously made. The path attribute in the <location> node points to the application path within the Default Web Site: <location path=“Default Web Site/Chapter06”> <system.webServer> <tracing> <traceFailedRequests> <add path=“*”> <traceAreas> <add provider=“ASP” verbosity=“Verbose” /> <add provider=“ASPNET” areas=“Infrastructure,Module,Page,AppServices” verbosity=“Verbose” /> <add provider=“ISAPI Extension” verbosity=“Verbose” /> <add provider=“WWW Server” areas=“Authentication,Security,Filter, StaticFile,CGI,Compression,Cache,RequestNotifi cations” verbosity=“Verbose” /> </traceAreas> <failureDefi nitions statusCodes=“200” /> 874 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 </add> </traceFailedRequests> </tracing> </system.webServer> </location> The default Failed Request Tracing setting in IIS 7.0 is to not allow the trace Failed Request settings to be confi gured beyond the server level. To change this, you’ll need to modify the section found within the applicationHost.confi g fi le and change the overrideModeDefault setting from Deny to Allow: <sectionGroup name=“tracing”> <section name=“traceFailedRequests” overrideModeDefault=“Deny” /> <section name=“traceProviderDefi nitions” overrideModeDefault=“Deny” /> </sectionGroup> Breakpoints: Extending IIS 7.0’s Tracing The theme of extensibility continues even into IIS 7.0’s failed request tracing. The ability for a developer who develops custom modules using IIS 7.0’s APIs to also push his or her module’s errors into the same error log used by IIS is arguably the most powerful feature in all of IIS 7.0. A developer who raises events through the life of a module can emit these events in IIS 7.0’s failed request logs in sequence with all other IIS events. It is important for system administrators and developers alike is to understand how these custom events will be persisted to the log fi le. Beyond that, they need to know how to easily distinguish between these custom events and those emitted by the core IIS server. How Developers Extend Their Module to Support Failed Request Tracing A potential topic in and of itself, we can’t turn a deaf ear to understanding how developers will take advantage of this feature. It is more important, though, to know how to fi nd the custom events than to help narrow the problem to custom code rather than in IIS’s core server. In this section, we will provide a sample of a module with events that are emitted to the trace log fi les in error conditions with the goal of showing how they live side by side with IIS’s core server events. The core principles in this sample will show you how any Web application on IIS 7.0 can interject its own application information into the combined trace fi le generated by IIS 7.0. Using Visual Studio C# Express Edition (which is a free download), let’s develop a Custom Error Module that we’ll use to override the default Error Module that ships with IIS 7.0. To develop an IIS 7 module or handler, we’ll need to install all the required components for VS C# Express or VB.NET to work on Microsoft Windows Vista: Troubleshooting 101: Diagnostics in IIS 7.0 • Chapter 17 875 ■ Microsoft Visual Studio Express Editions (C#, VB.NET, J#) ■ Visual Studio 2005 Service Pack 2 ■ Visual Studio 2005 Update for Windows Vista You can download and install these components (and it should be done in the order defi ned previously) from http://msdn.microsoft.com/vstudio/express/downloads/. Visual Studio C# Express Edition (VSCSE) provides the ability to compile in both Release and Debug modes. The main difference between the two when compiling your code base is that the Debug version of the DLL is a bit larger and includes the symbols (.pdb) fi le. VSCSE has a default setting of building (aka compiling) in the Release format. To enable Debug mode building, we’ll need fi rst expose the ability to make this change with Visual Studio: 1. With VSCSE running, click Tools | Options from the menu bar. 2. At the bottom-left corner of the Options window, check the Show all settings check box. 3. Expand Projects and Solutions and then click the General node. 4. Check the Show advanced build confi gurations check box. 5. Click the OK button (see Figure 17.13). Figure 17.13 VSCSE Options 876 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 Now that we have this confi gured, we can select the build type we’d like to use in compiling our application or class. Create and Compile To get started, let’s start the Microsoft Visual C# 2005 Express Edition development environment and create a new project: 1. Click the Windows button | All Programs | Microsoft Visual C# 2005 Express Edition. 2. From the top menu bar, click File | New Project. 3. Select Class Library and set the Name to HowToCheatIIS7. 4. Click OK (see Figure 17.14). Figure 17.14 Creating a New Project with Visual C# 2005 Express Edition To leverage the Microsoft.Web.Administration object model and to connect into the IIS pipeline, we’ll need to create a couple of references to our project: 1. Right-click the References folder and select Add References…from the context menu. 2. Within the Browse tab, navigate to the %WINDIR%\System32\InetSrv folder and select Microsoft.Web.Administration.dll, and then click the OK button. . administrators and developers alike is to understand how these custom events will be persisted to the log fi le. Beyond that, they need to know how to easily distinguish between these custom events and. bottom-left corner of the Options window, check the Show all settings check box. 3. Expand Projects and Solutions and then click the General node. 4. Check the Show advanced build confi gurations check. Specify Content to Trace page, select ASP.NET (*.aspx) and click Next. 6. From the Defi ne Trace Conditions page, check the Status Codes check box and enter 200 as the status code. 7. From the Select