Http error log windows

Microsoft Internet Information Services (IIS) is a popular web server used on Windows platforms to host websites, web applications, and services. Understanding how IIS handles logging is crucial for optimizing server performance, troubleshooting issues, and enhancing security.

IIS primarily maintains two types of logs:

1. Access Logs – Track incoming HTTP requests to your server.
2. Error Logs – Record server-side errors, failed requests, and application-level issues.

This guide will walk you through the structure, configuration, and practical use of both types of logs in IIS.

Log & Configuration File Locations

Before getting into the details, it’s helpful to understand where IIS stores its logs and configuration files.

Understanding IIS Access Logs

What Are Access Logs?

Access logs capture details of all incoming HTTP requests processed by IIS. They are invaluable for:

• Monitoring traffic patterns
• Identifying potential security threats
• Analyzing client behavior (e.g., pages visited, user agents)

Enabling and Configuring Access Logs

To enable and configure access logging in IIS:

1. Open IIS Manager:
   • Navigate to Sites > Your Website.
   • Double-click Logging under the IIS section.
2. Configure Log Settings:
   • Format: The default format is W3C, which records critical request data.
   • Log File Directory: Typically located in C:\inetpub\logs\LogFiles\.
   • Fields: You can customize which fields to log (e.g., client IP, user agent, status code).
3. Customizing Log Fields
   • Click on Select Fields to include or exclude specific details like the referrer, server port, or HTTP substatus.

Access Log Format

IIS uses the W3C extended log format, which includes details like the client IP, HTTP method, URL, and status codes.

Sample Access Log Entry:

#Fields: date time cs-method cs-uri-stem sc-status sc-bytes cs(User-Agent) c-ip
2024-11-14 10:15:23 GET /index.html 200 4523 "Mozilla/5.0" 192.168.1.10

Understanding IIS Error Logs

What Are Error Logs?

Error logs capture issues that occur while IIS processes requests. These logs are crucial for diagnosing server errors, application crashes, and configuration problems.

Types of IIS Error Logs

IIS uses multiple sources for logging errors:

1. HTTP Error Logs:
   • Located in C:\inetpub\logs\LogFiles\W3SVC<SiteID>.
   • Capture HTTP errors such as 404 (Not Found) or 500 (Internal Server Error).
2. Failed Request Tracing (FREB) Logs:
   • Provide detailed information on failed requests.
   • Located in C:\inetpub\logs\FailedReqLogFiles\W3SVC<SiteID>\.
   • To enable, go to IIS Manager > Failed Request Tracing Rules.
3. Windows Event Viewer:
   • Captures system-level errors, application crashes, and critical events.
   • Access via Event Viewer > Windows Logs > Application or System.

Configuring Error Logs

To enable Failed Request Tracing:

1. Open IIS Manager and select your website.
2. Click on Failed Request Tracing.
3. Enable the feature and set the number of trace files to keep.
4. Define specific conditions to capture, such as status codes (e.g., 500 errors).

Sample Error Log Entry (FREB)

<Event>
  <DateTime>2024-11-14T10:20:45.123Z</DateTime>
  <SiteID>1</SiteID>
  <RequestStatus>500</RequestStatus>
  <FailureReason>Module_Detail_Error</FailureReason>
  <ModuleName>FastCgiModule</ModuleName>
  <ErrorCode>0x8007000d</ErrorCode>
  <URL>/api/data</URL>
  <ClientIP>192.168.1.15</ClientIP>
</Event>

Explanation:

• The error log indicates a 500 Internal Server Error due to an issue with the FastCGI module.

Common Error Types

Here are some common IIS error messages:

Configuring Logs for Multiple Websites

If you are hosting multiple websites on the same IIS server, it’s useful to configure separate logs for each site:

1. In IIS Manager, select the site you want to configure.
2. Open Logging and specify a unique log directory.
3. Adjust the settings to include or exclude specific fields as needed.

Example:

• Site 1: Logs stored in C:\inetpub\logs\LogFiles\W3SVC1\
• Site 2: Logs stored in C:\inetpub\logs\LogFiles\W3SVC2\

Mastering IIS logs is essential for maintaining a stable and secure web environment. By properly configuring and analyzing access and error logs, you can optimize server performance, identify issues quickly, and enhance security.

Use this guide to improve your IIS logging setup and server management capabilities.

Your web application is throwing some sort of error or invalid response. Do you know how to troubleshoot IIS or ASP.NET errors on your servers? Luckily, Windows & ASP.NET provide several different logs where failed requests are logged.

You are probably familiar with normal IIS logs, but there are some other places to look if you are looking for more detailed error messages or can’t find anything in your IIS log files.

1. Standard IIS Logs

Standard IIS logs will include every single web request that flows through your IIS site. Via IIS Manager you can verify that your IIS logs are enabled and where they are being written to. 

You should find your logs in folders that are named by your W3SVC site ID numbers.

By default each logged request in your IIS log will include several key fields including the URL, querystring, and error codes via the status, substatus and win32 status. These status codes can help identify the actual error in more detail.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2016-09-13 21:45:10 ::1 GET /webapp2 - 80 - ::1 Mozilla/5.0 - 500 0 0 5502
2016-09-13 21:45:10 ::1 GET /favicon.ico - 80 - ::1 Mozilla/5.0 http://localhost/webapp2 404 0 2 4

The “sc-status” and “sc-substatus” fields are the standard HTTP status code of 200 for OK, 404, 500 for errors, etc. 

The “sc-win32-status” can provide more details that you won’t know unless you lookup the code. They are basic Win32 error codes.

2. Can’t find your request in the IIS log? HTTPERR is your IIS error log

Every single web request should show in your IIS log. If it doesn’t, it is possible that the request never made it to IIS, or IIS wasn’t running. Also, be sure that your IIS logging is enabled.

Incoming requests to your server first route through HTTP.SYS before being handed to IIS. These type of errors get logged in HTTPERR. Common errors are 400 Bad Request, timeouts, 503 Service Unavailable and similar types of issues. The built in error messages and error codes from HTTP.SYS are usually very detailed.

Where are the HTTPERR error logs?
C:\Windows\System32\LogFiles\HTTPERR

3. Look for ASP.NET exceptions in Windows Event Viewer

By default ASP.NET will log unhandled 500 level exceptions to the Windows Application EventLog. This is handled by the ASP.NET Health Monitoring feature. You can control settings for it via system.web/healthMonitoring in your web.config file.

Very few people realize that the number of errors written to the Application EventLog is rate limited. So you may not find your error! By default it will only log the same type of error once a minute. You can also disable writing any errors to the Application EventLog. 

Still can’t find your exception?

Depending on if you are using WebForms, MVC, Web API, WCF or other frameworks, you may have issues with ASP.NET not writing any errors at all to ASP.NET due to compatibility issues with the health monitoring feature. 

4. Enable Failed Request Tracing for an advanced IIS error log

Failed request tracing (FRT) is probably one of the least used features in IIS. It provides robust IIS logging and works as a great IIS error log. FRT is enabled in IIS Manager and can be configured via rules for all requests, slow requests, or just certain response status codes.

The only problem with FRT is it is insanely detailed. It tracks every detail and every step of the IIS pipeline. You can spend a lot of time trying to decipher a single request.