Working with WCF services in IIS can be particularly frustrating when all you get is that generic "failed request" blue box. As developers, we need detailed error information - the exception message, stack trace, and underlying causes - to effectively debug issues. Here's how to get the real diagnostic data you need.

The fastest way to get detailed errors is to modify your WCF service's web.config file:

<system.web>
  <customErrors mode="Off"/>
</system.web>
<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  <behaviors>
    <serviceBehaviors>
      <behavior>
        <serviceDebug includeExceptionDetailInFaults="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

If your Failed Request Tracing isn't working, let's ensure proper setup:

1. Open IIS Manager
2. Select your site
3. Double-click "Failed Request Tracing Rules"
4. Click "Add" in the Actions pane
5. Configure for:
   - Status codes: 200-999
   - Event severity: Error
   - Providers: WWW Server, ISAPI Extension

For more control, implement IErrorHandler in your WCF service:

public class CustomErrorHandler : IErrorHandler
{
    public bool HandleError(Exception error)
    {
        return true;
    }

    public void ProvideFault(Exception error, 
        MessageVersion version, ref Message fault)
    {
        var faultException = new FaultException<string>(
            $"Error: {error.Message}\nStack: {error.StackTrace}");
        
        var messageFault = faultException.CreateMessageFault();
        fault = Message.CreateMessage(version, messageFault, null);
    }
}

• Check Windows Event Viewer for system-level errors
• Enable WCF tracing in web.config for detailed protocol information
• Use Process Monitor to track file and registry access issues
• Test with WCF Test Client before IIS deployment

Remember that detailed error reporting has overhead. In production:

• Implement proper logging instead of exposing details
• Use health monitoring (system.web/healthMonitoring)
• Consider ELMAH for comprehensive error logging

When working with WCF services hosted in IIS 7.5, developers often encounter the infamous blue "Failed Request" error page that provides minimal information. This generic error handling makes debugging significantly harder since you can't see the actual exception message or stack trace that would help identify the root cause.

First, let's ensure IIS is configured to show detailed errors:

<configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
  <system.web>
    <customErrors mode="Off" />
    <compilation debug="true" />
  </system.web>
</configuration>

For WCF services, you need to enable includeExceptionDetailInFaults in your service behavior:

<system.serviceModel>
  <behaviors>
    <serviceBehaviors>
      <behavior name="debugBehavior">
        <serviceDebug includeExceptionDetailInFaults="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
  <services>
    <service behaviorConfiguration="debugBehavior" name="YourService">
      <endpoint address="" binding="basicHttpBinding" contract="IYourService" />
    </service>
  </services>
</system.serviceModel>

If your Failed Request Tracing logs remain empty, verify these settings:

1. Ensure the trace provider "WWW Server" is enabled
2. Check that the tracing directory has proper write permissions
3. Verify you've configured the correct status codes (500-599) for tracing
4. Restart IIS after configuration changes

For more control, implement a global error handler in your WCF service:

public class GlobalErrorHandler : IErrorHandler
{
    public bool HandleError(Exception error)
    {
        return true;
    }

    public void ProvideFault(Exception error, 
                           MessageVersion version, 
                           ref Message fault)
    {
        var newEx = new FaultException<ExceptionDetail>(
            new ExceptionDetail(error),
            new FaultReason(error.Message),
            FaultCode.CreateSenderFaultCode());
        
        MessageFault msgFault = newEx.CreateMessageFault();
        fault = Message.CreateMessage(version, msgFault, newEx.Action);
    }
}

When browser rendering hides details, use cURL to inspect raw responses:

curl -v http://yourserver/yourservice.svc