Learn how to troubleshoot IIS 5.0 and IIS 4.0 problems
Last month, I gave you a quick look at IIS architecture. This month, I show you how to start applying that knowledge to isolating and fixing problems you might encounter. The information here is second nature to most administrators, but many in the industry, including some support personnel, tend to overlook it. Combining this information with a good understanding of how IIS works can easily narrow down your search for the problem.
Gathering Information
The first and most important thing to do when trying to resolve an IIS problem is to review all the facts you already have. Ask yourself these key questions.
What symptoms are you seeing? In this case, you're looking for the problem type. You could have a Dr. Watson error or an Access Violation error. The server might appear to hang and not serve pages. It could hard lock to the point of not running applications. The client might be receiving the ASP 0115 A Trappable error has occurred error message, but the server still appears to run.
If you're experiencing a hang in which Active Server Pages requests appear to stop responding, can you access an .htm page? This question is a crucial part of isolating problems. Active Server Pages (ASP) requests have a unique pool of worker threads (provided by COM+ in IIS 5.0 or Modular Transaction System—MTX—in IIS 4.0). If ASP is hung but the server can still serve .htm or static pages, you want to concentrate your efforts specifically on ASP. If everything is hung, you know you need to investigate IIS's core thread pool, known as the Asynchronous Thread Queue (ATQ).
Was the server working before this problem occurred, or is this system new? If the server was working before, what changed? Did you add code, change a setting, or move the site to a new machine? If this server was working fine last week, you need to look at what changed. Don't overlook anything here, because if everything was fine and it's not now, something changed. Knowing what changed can at least give you a starting point in your investigation. Code additions or revisions are often culprits in problems with Web servers.
What does the problem site or server do? In other words, what kind of code is on the site and does it talk to databases, back-end servers, and so on? This question can sometimes be difficult to answer. If the machine is hosting one site that uses VBScript and ADO to retrieve data from a back-end Microsoft SQL Server, you have a pretty good idea of the components involved. If, however, the server is an ISP machine that hosts 50 different sites, each written by a different client, the problem becomes more difficult. I usually recommend that ISPs and administrators hosting multiple sites keep a log with the general functionality of the different sites they're hosting. Your list will never be perfect because you can't guarantee that your customers will always tell you everything, but you'll have a good starting point.
Is the problem reproducible on demand? Can you perform a series of steps that cause the problem to occur every time? If so, can you perform those steps on a different machine with the same application and have the problem occur on the other machine? This process can tell you whether the problem is in the code or setup or in the settings of a specific machine. Also, if you can't reproduce the problem on another machine, start looking at the differences between the two machines.
Do relevant entries appear in Event Viewer? This information is quick and easy to retrieve. Often, you can find a problem simply by looking at the messages in Event Viewer. For example, if you're having trouble getting an ASP page to return data from a SQL Server machine and you see an error in Event Viewer stating that an ADO error has occurred (along with an error code), you can go to Microsoft's Support site and search the Knowledge Base for the error. Chances are that you'll find one or more articles that address the error.
What's required to get the server running again? Discover this information systematically. For example, if the Web sites are hung, first try stopping and restarting the Web service by choosing Start, Run, then typing net stop w3svc. Restart the service by choosing Start, Run, then typing net start w3svc. If that process doesn't work, try stopping the entire Web server by choosing Start, Run, and typing net stop iisadmin /y, then restarting the server by choosing Start, Run, and typing net start w3svc. Keep in mind that you also have to restart any other services you had running in inetinfo, such as FTP and SMTP. If this process still doesn't work, you need to restart the server on which IIS runs.
What does the client see? If a client reports trouble accessing the site, ask the user for specifics. Remember that some newer browsers have a setting for Friendly HTTP errors. This setting masks the real error and doesn't let you get enough information. Ask the client to disable this setting, then try to reproduce the error.
Using the Information
After you've gathered the information, you can start troubleshooting. Over the next few months, I'll cover many scenarios that show you how to use the information you've gathered. I'll also show you how these different pieces of information relate to and build on one another. This month, however, to give you a quick example of what I'm talking about, consider the following situation.
Prev. page
[1]
