862 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 Let’s say that we don’t want to host this particular information within the applicationHost.confi g fi le, but we want the Web site developer/administrator to control it from their end. To do this, we could easily remove this XML from the applicationHost.confi g fi le and move it into the web.confi g fi le, which should be at the root folder for that application. The web.confi g should now look like the following XML: <confi guration> <system.webServer> <httpErrors> <remove statusCode=“500” subStatusCode=“-1” /> <error statusCode=“500” prefi xLanguageFilePath=“” path=“D:\\web\Chapter06\ Error.aspx” responseMode=“File” /> </httpErrors> </system.webServer> </confi guration> Custom Error Module What drives the custom errors is the CustomErrorModule module, which is defi ned as a default module in the applicationHost.confi g fi le. The following is a snapshot of a simple web.confi g fi le that will override the applicationHost.confi g fi le setting by removing the CustomErrorModule from the list of modules that will be used per request: <confi guration> <system.webServer> <modules> <remove name=“CustomErrorModule” /> </modules> </system.webServer> </confi guration> If you now navigate to a fi le or folder that doesn’t exist at http://<site with above web.confi g>/ fi le_not_here, you’ll get a blank page. This is because the web.confi g removed the only module that would capture the error and provide a response. If you remove the CustomErrorModule at a Web site or application level using IIS Manager, you’ll end up with the following web.confi g (assuming that no other changes were made to the Web application): <confi guration> <system.webServer> <modules> <clear /> <add name=“HttpCacheModule” type=“” preCondition=“” /> <add name=“StaticCompressionModule” type=“” preCondition=“” /> Troubleshooting 101: Diagnostics in IIS 7.0 • Chapter 17 863 <add name=“DefaultDocumentModule” type=“” preCondition=“” /> <add name=“DirectoryListingModule” type=“” preCondition=“” /> <add name=“ProtocolSupportModule” type=“” preCondition=“” /> <add name=“StaticFileModule” type=“” preCondition=“” /> <add name=“AnonymousAuthenticationModule” type=“” preCondition=“” /> <add name=“RequestFilteringModule” type=“” preCondition=“” /> <add name=“CustomErrorModule” type=“” preCondition=“” /> <add name=“IsapiModule” type=“” preCondition=“” /> <add name=“BasicAuthenticationModule” type=“” preCondition=“” /> <add name=“HttpLoggingModule” type=“” preCondition=“” /> <add name=“RequestMonitorModule” type=“” preCondition=“” /> <add name=“IsapiFilterModule” type=“” preCondition=“” /> <add name=“Confi gurationValidationModule” type=“” preCondition=“” /> <add name=“OutputCache” type=“System.Web.Caching.OutputCacheModule” preCondition=“managedHandler” /> <add name=“Session” type=“System.Web.SessionState.SessionStateModule” preCondition=“managedHandler” /> <add name=“WindowsAuthentication” type=“System.Web.Security. WindowsAuthenticationModule” preCondition=“managedHandler” /> <add name=“FormsAuthentication” type=“System.Web.Security. FormsAuthenticationModule” preCondition=“managedHandler” /> <add name=“DefaultAuthentication” type=“System.Web.Security. DefaultAuthenticationModule” preCondition=“managedHandler” /> <add name=“RoleManager” type=“System.Web.Security.RoleManagerModule” preCondition=“managedHandler” /> <add name=“UrlAuthorization” type=“System.Web.Security.UrlAuthorizationModule” preCondition=“managedHandler” /> <add name=“FileAuthorization” type=“System.Web.Security. FileAuthorizationModule” preCondition=“managedHandler” /> <add name=“AnonymousIdentifi cation” type=“System.Web.Security. AnonymousIdentifi cationModule” preCondition=“managedHandler” /> <add name=“Profi le” type=“System.Web.Profi le.Profi leModule” preCondition=“managedHandler” /> <add name=“UrlMappingsModule” type=“System.Web.UrlMappingsModule” preCondition=“managedHandler” /> <add name=“WindowsAuthenticationModule” type=“” preCondition=“” /> <add name=“IpRestrictionModule” type=“” preCondition=“” /> <add name=“CustomLoggingModule” type=“” preCondition=“” /> <add name=“FailedRequestsTracingModule” type=“” preCondition=“” /> </modules> </system.webServer> </confi guration> 864 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 This web.confi g starts off by clearing all previously defi ned modules that would have be inherited by the web.confi g of the Default Web Site (because this application is within that particular site) and the applicationHost.confi g fi le. The IIS Manager then explicitly defi nes each additional module for us but does not add in the one module we wanted to remove. Let’s say we use the same web.confi g and now navigate to http://<site with above web.confi g>/ fi le_not_here.aspx (see Figure 17.6). Figure 17.6 A Server Error You now see that you’ll get an error response from ASP.NET. Even if you set existingResponse to a value of Replace, which would normally have IIS do the error response instead of ASP.NET when an error is generated by ASP.NET, the response will still be handled by ASP.NET. This is because the previous web.confi g setting removed the module that would have handled the error. Thus, ASP.NET will continue to generate the error. Troubleshooting 101: Diagnostics in IIS 7.0 • Chapter 17 865 Inside IIS 7.0’s Failed Request Tracing Getting the current state of a request made to an IIS 7.0 server is easier than ever before when we use IIS 7.0’s Failed Request Tracing. This feature allows an inside view to particular requests that are currently in process and how long they have been executing. IIS’s failed request tracing was designed in such a way that you shouldn’t need to be present when a problem occurs; rather, you should simply be prepared for the problem if it arises. The success of this new feature depends solely on your ability to confi gure the appropriate rules for your Web applications prior to failures. Failed Request Tracing Architecture Although the underlying feature behind failed request tracing was introduced in Windows Server 2003 (Enterprise Tracing for Windows), its awareness and usability didn’t become fi rst class for IIS customers until IIS 7.0. The key to using this new feature is to understand how IIS 7.0’s modularized core server emits events that are captured and stored for later retrieval. At the heart of what allows Failed Request Tracing (FRT) is Enterprise Tracing for Windows (ETW), a platform component of the Windows Operation System. ETW was fi rst leveraged by IIS with IIS 6.0 Service Pack 1. ETW is a kernel mode component that will keep track of all tracing events within nonpaged memory and will fl ush out the events to disk in a nonsequential order (important to note for navigating the trace fi les later). ETW provides a mechanism for applications to plug into the tracing infrastructure via a provider model. Each provider will have the opportunity to write relevant data per session or page requests as it relates to IIS 7.0. With IIS 6.0/Service Pack 1, administrators had to interact directly with ETW via the command line to use ETW tracing with IIS. In addition, the ETL log fi le was diffi cult to use and often needed tools such as Log Parser (part of the IIS Diagnostics Toolkit at www.iisdiagnostics.com) to get to the relevant tracing information. Furthermore, a limited set of providers were available for tracing in IIS 6 and there was no “easy” way to add additional providers into the tracing pipeline from an ASP.NET/IIS application. IIS 7.0 reduces the complexity in enabling and managing tracing data. Administrators can enable tracing from within the new IIS 7.0 administration console. Web developers can quickly and effi ciently plug into the IIS 7.0 tracing pipeline (which uses ETW as the platform) with a few lines of additional code in their application. For more information on Enterprise Tracing for Windows and the improvements to ETW in Windows Vista, you’ll fi nd a great article on the Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/msdnmag/issues/07/04/ETW/. Confi guring IIS 7.0’s Failed Request Tracing By default, IIS 7.0’s tracing isn’t enabled on Windows Vista. It is available, though, if it’s installed during the setup process. It is important to understand how to enable tracing and create rules to capture the events you are looking for. A key aspect of failed request tracing is the understanding of how to scope rules to remove noise from the log fi les and help narrow down the problem. In such cases, you might only want to establish rules for a particular error or condition. Here we will walk you through how to best use this feature of tracing. 866 Chapter 17 • Troubleshooting 101: Diagnostics in IIS 7.0 Enable Tracing for IIS 7.0 To use tracing in IIS 7.0, we fi rst must add that in Windows Vista: 1. Click the Windows button and navigate to Control Panel. 2. From Control Panel Home (not Classic View, although you could take that route as well), click Programs | Turn Windows features on or off. 3. From within the Windows Features window, expand Internet Information Services | World Wide Web Services | Health and Diagnostics. 4. Check the Tracing check box and then click the OK button (see Figure 17.7). Figure 17.7 Turning Windows Features on and off . It is important to understand how to enable tracing and create rules to capture the events you are looking for. A key aspect of failed request tracing is the understanding of how to scope rules. within the Windows Features window, expand Internet Information Services | World Wide Web Services | Health and Diagnostics. 4. Check the Tracing check box and then click the OK button (see Figure. type=“System.Web.Security. DefaultAuthenticationModule” preCondition=“managedHandler” /> <add name=“RoleManager” type=“System.Web.Security.RoleManagerModule” preCondition=“managedHandler” /> <add name=“UrlAuthorization”