Resolving Issues with Your Application Using IIS Logs

If you are like most software developers, your code often doesn’t work the first time you write and test it—and a good portion of your job is dedicated to troubleshooting errors caused by the configuration of your application server or the code you have written. This type of troubleshooting typically involves analyzing log files.

If you are running your application on Microsoft IIS, you may find yourself looking into the IIS logs your application produces. In this article, we’ll walk through the process of troubleshooting application issues utilizing IIS logs. Through the use of a sample application, I will show a few error codes produced by IIS and how to resolve them to get the application working as designed.

What is IIS and how do we use the log files to troubleshoot?

What is IIS? Where are the IIS log files located? And how do we read and utilize them to solve issues with our application? These are all questions you may ask yourself as you decide to use IIS to run your application for the first time. Luckily, they all have simple answers.

IIS (Internet Information Services) is a web server provided by Microsoft. A web server is used for storing, processing and serving web pages to a requesting client. When you set up your website on IIS and logging is enabled, the server will write a log statement to a log file when an HTTP transaction occurs. Using IIS 10.0, the file format will list the following information (in this particular order) with each log statement:

• date (YYYY-MM-DD)
• time (HH:MM:SS)
• s-ip — server IP address
• cs-method — the action being taken by the client; examples include GET or POST)
• cs-uri-stem — the file being requested
• cs-uri-query — the query being performed by the client
• s-port — port number being accessed by the client
• cs-username — the name of the user accessing the server (if not an authenticated user, it will be represented by a hyphen in the statement)
• c-ip — IP address of the client accessing the web server
• cs(User-Agent) — browser used by client to access web server
• cs(Referer) — previous site visited by the user
• sc-status — status of the action, represented by a success or error code
• sc-substatus — status code to help further break down the success or error code to provide greater insight
• sc-win32-status — Windows terminology used to define status of the action
• time-taken — the length of time taken to complete the action, in milliseconds

Debugging an application using IIS logs

As an example, I built a simple PHP web application and configured IIS on my local machine to host the application. The goal is to show a potential real-life situation where IIS logs can assist the software developer in debugging activities.

The first link I tried to get to was the default page for the application directory located at the following URL: http://localhost/samplephp/forms/

I was met with the following error:

Checking the IIS logs, I found the corresponding entry that listed the properties mentioned above in the following format:

#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

2017-11-19 21:55:25 ::1 GET /samplephp/forms/ – 80 – ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/62.0.3202.94+Safari/537.36 – 403 14 0 1159

2017-11-19 21:55:25 ::1 GET /favicon.ico – 80 – ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/62.0.3202.94+Safari/537.36 http://localhost/samplephp/forms/ 404 0 2 9

The first entry in the IIS log file is where we need to direct our attention to resolve the issue. As we can see from the cs-method and cs-uri-stem portions of the entry, this is where the GET request is processed for the URI /samplephp/forms. Further into the entry, we can see that the status is 403, and the substatus is 14. This error is thrown to tell us that our issue is more than likely caused by one of the following:

1. The IIS server is not configured to load the homepage correctly.
2. The IIS server should be configured to allow us to browse the resources in the directory denoted by this URL, but it is not.

In this particular situation, the problem is number 1. Our IIS server is clearly not configured to load our homepage properly. This can be solved by opening the IIS Manager and navigating to the directory represented by the URL we are trying to visit. Highlighting the directory and then double-clicking on the Default Document icon on the screen will open a list of valid default documents that will be looked for and served when this URL is visited. The name of the PHP file I am trying to load as the home page for this directory is sample_form.php. As you can see in the screenshot below, that is not listed under Default Documents:

To fix the error, we should add sample_form.php to the list of valid Default Documents and position this entry at the top of the list so that it is the first document searched for when this URL is visited. In doing this, we can avoid a different default document being served if a file with one of the other names in the list is ever added to the SamplePHP/forms directory.

After adding the entry and moving the document to the top of the list, the Default Documents section in IIS Manager appears as follows:

The next step is to restart the IIS server and then navigate to the problem URL as before. After doing so, the following page is served without issue:

Conclusion

It’s fair to say that a good portion of a software developer’s time is spent testing and debugging his or her applications. Microsoft’s IIS is equipped with logging capability that can make a software developer’s life easier as they try to work through the bugs that will inevitably come up. Whether the error is one that requires a change to the IIS server configuration, or one that requires a change to the application code itself, the IIS logs can assist by providing useful error codes to indicate the cause of the problem at hand.