Solving IIS Application Problems

Track and solve problems with the IIS Exception Monitor

Back in the early days of the Web craze, Web sites were static HTML pages and images that administrators rendered in a browser. The Web server didn't do much except process the request for a file and send the file's contents across the wire via HTTP. Today, administrators face complex problems with Web application servers.

Administrators now have Web servers that are application servers. Organizations create powerful applications on these servers and link these applications to databases and a myriad of other systems. Web servers no longer merely send the contents of a file over the wire. Instead, Web servers must process or manage the processing for a variety of technologies and orchestrate an integrated exchange of information between users and the server. This entire process is complex and can easily break down.

In Process vs. Out of Process
An advantage to using Microsoft Internet Information Server (IIS) 4.0 is its ability to run applications either in process or out of process. By default, IIS 4.0 runs each application in process (i.e., in the same process namespace as IIS). If an application uses the default setting, the IIS namespace hosts the application in the IIS process space. All the applications running in process on a Web server run in the inetinfo.exe process. To see the in process application load, you can use Task Manager or Performance Monitor to view the inetinfo.exe process CPU utilization.

Hosting applications in the IIS process space lets the applications make the most use of the server's resources and perform optimally. For example, the FMStocks high-performance application, which Vertigo Software created for Microsoft, runs everything in process (i.e., in inetinfo.exe). Running all applications in the IIS 4.0 namespace also has a downside. When you run an application in the IIS 4.0 namespace, that application can affect other applications. If one piece of an application crashes, that piece can bring down the entire application. If a logic error causes part of the application to fail, this error doesn't typically affect IIS or other applications. However, if a part of the application crashes because that part tried to access memory outside its process space, that part will bring down IIS and other applications.

The first step I take to resolve IIS problems is to isolate them. If you determine that an application routinely fails and brings down the Web server, you can configure that application to run out of process to prevent the Web server from crashing until you determine the cause. You can use an application's Properties page to make the application run out of process (i.e., in a separate memory space). Screen 1 shows the Properties page for my test application, MTSTester.

Web sites that run only IIS don't require frequent reboots or tweaking because IIS is a stable platform when running alone. For example, my ISP has 17 reliable servers that run IIS 4.0 with Windows NT 4.0 Service Pack 5 (SP5), and host applications that use HTML, Active Server Pages (ASP), and COM objects.

Running an application in process takes on a new meaning when your application uses COM objects. COM objects provide a tremendous amount of power for an application, but they require management such as determining the component's location, controlling who has access to the component, and setting procedures for replacing components.

Part of managing a COM object requires understanding its function. Because a COM object is a compiled application, the object's code and how the object works isn't viewable, which makes inspecting the application and determining the problem difficult. You might also use COM objects that you purchased from another company, which further removes you from the object's code. When a COM object loads in the IIS process, its code runs in the same memory space as IIS.

My ISP works hard to make sure its COM objects are reliable. However, during the second half of 1998, I noticed that my site would perform well for a period of time, then gradually slow down and die. The performance decline took place over several weeks or months and seemed erratic. After the ISP's technical manager discovered that my site ran out of process, he configured the site to run in process and the problem disappeared.

Since the change, I've spoken with several people who've had similar problems. The consensus is that out of process applications on IIS 4.0 might exhibit long-term stability problems that eventually require you to reboot the server. I know some administrators who run their intranet applications out of process to keep the servers from crashing and reboot the servers periodically. These reboots work for these sites, so the administrators live with the inconvenience.

IIS 4.0 uses Microsoft Transaction Server (MTS) to manage in process and out of process applications. An MTS package is the container for one or more COM components and defines the namespace for the components. The MTS executable that runs MTS packages is mtx.exe. You can use Task Manager to watch the instances of mtx.exe that MTS creates as IIS runs out of process applications.

Administrators run MTS packages in the IIS process space to improve performance. You need management privileges in MTS Explorer to make MTS packages run in the IIS process space. MTS packages can also run in a server process (i.e., out of process as Server Packages) or in the process of the calling application. You can use the package's Properties page to change the package from an MTS server application and make the package run in the inetinfo.exe process. To access this page, start MTS Explorer from the Programs menu. Expand the Computers folder, the folder of the computer you want to change, and the Packages Installed folder. Then, select the package you want to change and the package's Properties page. On the Activation tab, select Library Package, as Screen 2 shows, then click OK. After you select Library Package, objects in this package will run in the process space of the calling application (i.e., inetinfo.exe for IIS).

To isolate an IIS problem, change the settings for any MTS packages that IIS uses and make sure the packages are running as Server Packages rather than as Library Packages (i.e., in process). Performance might suffer, but IIS will keep running if an object running on MTS is causing the problem.

IIS Exception Monitor
The IIS Exception Monitor helps administrators determine the cause of IIS problems. Microsoft designed this tool to watch IIS and take action when an exception occurs. The action that IIS Exception Monitor takes depends on how you configure the tool.

To obtain the IIS Exception Monitor, see the Microsoft article "INFO: Troubleshooting Exceptions in Internet Server Products" (http://support.microsoft.com/support/kb/articles/q160/3/60.asp). This article contains a link to download the IIS Exception Monitor and documentation. I recommend that you download the documentation because it explains how to use the tool. The README file that installs with IIS Exception Monitor also provides information about the tool.

The IIS Exception Monitor installation is simple and takes only minutes. To install the tool, you run ixcptmon.exe on your IIS server. You'll find this executable in your Programs menu (my test installation didn't install a Programs group) or in the directory you downloaded it to (the default is C:ixcptmon). When you run ixcptmon.exe, a wizard guides you through the configuration.

After the IIS Exception Monitor starts, click Next in the first dialog box. Then, select Yes, Verify the IIS symbols that I have installed in the second dialog box and click Next. These actions cause the IIS Exception Monitor to review your system and determine any symbol files your system needs. The symbol files contain data that the IIS Exception Monitor uses to debug the IIS process and let the IIS Exception Monitor determine the location of errors.

After the IIS Exception Monitor determines which symbol files your system requires, the tool lists the necessary files, as Screen 3 shows. The display varies depending on the files that are on a system. When the analysis process completes, select the Determine which symbol packages can be installed from Microsoft's Internet Site check box, then click Next. From the Download Symbols dialog box that opens, select the first symbol file in the list and click Download. Click Next to download the file. Select each symbol file in succession to download the files. (Some of these files take several minutes to download.) After the symbol files download, the program prompts you to install them.

To start an IIS Exception Monitor session, run ixcptmon.exe again. If the executable is still running after you install the symbols, you can use the active session. If you restarted the executable, click Next in the Check Symbols dialog box, select No, I am confident that the symbols are installed correctly, then click Next.

In the Process Options dialog box that opens, you can select the type of process you want to monitor. The choices include in process (i.e., inetinfo.exe), out of process (i.e., applications you mark to run in a separate address space), or other process (i.e., any other process). Select In Process, then click Next to open the Session Options dialog box.

The Session Options dialog box determines how the IIS Exception Monitor will run. You can have the tool monitor one session or put the IIS Exception Monitor into Recursive Mode to monitor the processes until an exception occurs. When the IIS Exception Monitor finds an error in Recursive Mode, the tool updates the log, kills the inetinfo.exe process, restarts inetinfo.exe, and starts monitoring again. When the tool detects a serious error in this fail-safe mode, it kills IIS and restarts the server.

You can use two methods to set Recursive Mode. You can select the Enable Recursive Mode check box from the Session Options dialog box, or you can use the /r switch from a command prompt to start ixcptmon.vbs. You can also use this switch from a command prompt to turn off Recursive Mode.

The Session Options dialog box also lets you enter an address to send automatic alerts to when an exception occurs. You can use Net Send to enter a system name or username in the Notify Admin text box. If you have Collaboration Data Objects (CDO) installed and configured on the system, you can also use an email address for alerts. To specify the system name or email name, you can use the /notify switch and enter the email name from a command prompt.

The Manual setting in the Session Options dialog box starts the IIS Exception Monitor in manual (i.e., support) mode. You need to use this mode when you place a technical support call with Microsoft and you're working with a support engineer. In the manual mode, you can connect your server to the Internet and the support engineer can remotely access the system to work with you to solve your problem.

After you configure the Session Options, click Next to display the Start Monitoring dialog box, then click Run This Monitoring Session. This selection starts the monitoring session and makes the IIS Exception Monitor run ixcptmon.vbs with the appropriate switches. When ixcptmon.vbs starts, a command prompt window opens. Don't close the command prompt window because this window is the execution window for ixcptmon.vbs. After the session starts, click Next to display the Session Status window. This window is your interface into the IIS Exception Monitor process.

From the Session Status dialog box, you can view the active session or the log files for previous sessions. Select a log to view, as Screen 4 shows, and click View Log to access the log files that the IIS Exception Monitor creates. You must stop the monitoring process before you can view log files. To stop monitoring and stop and restart IIS, open the command prompt window for the tool and press Ctrl+C. Then, run the IIS Exception Monitor again to view the logs.

The View Log button in the Session Status dialog box opens the Log window, which Screen 5 shows. This window provides several options for viewing information about the status of the log session and IIS. You can use several buttons to access these options.

You can also use the IIS Exception Monitor to kill the inetinfo.exe process so that you can restart IIS. During installation of the IIS Exception Monitor, kill.exe installs in the ixcptmonbin folder. Ixcptmon.vbs runs kill.exe when the inetinfo.exe process requires stopping and restarting. You can also run kill.exe from a command prompt to stop inetinfo.exe or another process. For example, to kill inetinfo.exe you can issue the kill -f inetinfo.exe command. Kill.exe is also available in the Microsoft Windows NT Server 4.0 Resource Kit.

Error Resolution
To isolate and work around IIS problems, you can change an application's namespace and make the application run out of process. After you set the applications to run out of process, you can safely test the applications in an environment that won't affect IIS. You can also change the settings for MTS packages that IIS uses to make sure the packages run as Server Packages. To further track and solve IIS errors, you can use the IIS Exception Monitor to help you research the location where problems occur within IIS application components.