Microsoft KB Archive/837518

= How to install IIS 5.0 debug tools on an Application Center 2000 cluster =

Article ID: 837518

Article Last Modified on 8/12/2004

-

APPLIES TO


 * Microsoft Application Center 2000 Service Pack 2
 * Microsoft Internet Information Services 5.0

-



SUMMARY
''Microsoft Application Center 2000 replicates IIS settings from the cluster controller to the cluster members. This replication behavior can cause issues with IIS debug tools. This article lists steps to install the IIS debug tools on the cluster controller. The article also describes how to use automatic synchronization from the Application Center 2000 cluster controller to the member servers to set up and configure the debug tools on the members instantaneously.''



INTRODUCTION
If a Web application is causing the Internet Information Service to quit unexpectedly (crash) or to stop responding (hang), an IIS support professional may request that you install the IIS debug tools to help troubleshoot the problem. This step-by-step article describes how to install the IIS debug tools on the cluster controller. The article also describes how to use the Application Center 2000 automatic synchronization in the cluster to set up and configure all the cluster members.

Note These steps are written explicitly for the Microsoft Internet Information Server 5.0 product that is included only with Microsoft Windows 2000.

This article assumes that all members of the Application Center 2000 cluster are configured for automatic synchronization. You have to stop and restart the IIS Admin Service on each server.

This article discusses two typical methods that you can use to set up the IIS debug tools:
 * To capture a Web application that stops responding
 * To capture a Web application that quits unexpectedly

The two implementations are similar because they both use the IISCrashHangAgent filter. However, to capture a Web application that quits unexpectedly, you also have to do the following:
 * Perform some special configurations in both IIS and the registry.
 * Attach a debugger from a console session. Avoid attaching the debugger to the IIS processes by using a terminal services session. If you cannot use a console session, the IIS support professional can provide alternatives. However, a console session is the best method to use and is the easiest method to use.



MORE INFORMATION
If IIS stops responding or if IIS quits unexpectedly, you can set up the IIS debug tools to capture the Web application.

This section discusses how to set up the IIS debug tools to capture a Web application that behaves this way on any server in an Application Center 2000 cluster.

Note This article assumes that the %SystemDrive% is the C drive.

How to set up the IIS debug tools to capture a Web application that stops responding (hangs)
 Install the IIS debug tools on the cluster controller only.  Install the tools. Accept the default values during the installation. Do not choose to restart IIS after the installation. You will restart IIS later.

To download the debug tools, visit the following Microsoft Download Center Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en

After the tools are installed, the files are located in the following folder on the server:

%SystemDrive%\IISDebugTools

 Edit the Internet Server API (ISAPI) filter in the properties of the WWW Service Master.  Open the Application Center 2000 Microsoft Management Console (MMC). Open Internet Information Services, right-click the server name for the cluster controller, and then click Properties.</li> Click Edit for the WWW Service Master properties.</li> On the ISAPI Filters tab, click the filter that is named IISCrashHangAgent, and then click Edit.

Notice that a red down arrow appears next to the filter. This arrow indicates that the filter is not loaded in memory because you have not restarted the IIS Admin Service yet.</li>  Locate the following executable path: \\?\C:\IISDebugTools\IISCHAgent.dll Change the previous executable path to the following executable path: C:\IISDebugTools\IISCHAgent.dll </li> Click OK until the master properties dialog box is closed.

Note This change will limit the path length that the tools can work with. However, this limitation is mitigated if you keep the file paths short in the .ini file that is described in step 8 (the IISchagent.ini file).</li></ol> </li> Create a virtual directory to the debug tools folder to replicate the files to the other servers.  Right-click the Application Center 2000 administrative site, click New, and then click Virtual Directory. The Virtual Directory Creation Wizard starts.</li> Click Next, and then type debug in Alias.</li> Click Next, and then move to the C:\IISDebugTools folder.</li> Click Next two times, and then click Finish to create the virtual directory.</li></ol> </li> Use Windows Explorer to create two folders.  Open Windows Explorer on the cluster controller and move to the C:\IISDebugTools folder.</li> In C:\IISDebugTools, create a folder that is named Logs, and then create a folder that is named History .</li></ol> </li> Use the Application Center 2000 MMC to exclude from synchronization the folders that you created in the previous step. <ol style="list-style-type: lower-alpha;"> <li>In the left pane, expand the cluster name so that you can see Synchronizations.</li> <li>Right-click Synchronizations, and then click Properties.</li> <li>Add to the list of exclusions the two new folders that you created earlier: C:\IISDebugTools\Logs and C:\IISDebugTools\History.</li></ol> </li> <li>Reset the IIS Admin Service on each server in the cluster.

You can reset the IIS Admin Service on each server without disrupting production. You can do this from the Application Center 2000 Microsoft Management Console (MMC). If you use a third-party load balancing solution instead of network load balancing, set the servers offline by using the load balancer. To do this, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>Drain the current connections for an appropriate time for the applications that are running on the Web site.</li> <li>Set each server offline, one at a time.</li> <li>After the server is offline, restart the IIS service, and then set the server online again.</li></ol>

By repeating this process for each server in the cluster, the Web applications will remain available.</li> <li>Move the IISCrashHangAgent ISAPI to the top of the list. <ol style="list-style-type: lower-alpha;"> <li>Open the Application Center 2000 MMC.</li> <li>Open Internet Information Services, right-click the server name for the cluster controller, and then click Properties.</li> <li>Click Edit for the WWW Service Master properties.</li> <li>On the ISAPI Filters tab, click the filter that is named IISCrashHangAgent.

Notice that a green arrow now indicates that the filter is loaded in memory.</li> <li>Move the filter to the top of the list. To do so, click the Up button.</li> <li>Click OK until the master properties dialog box is closed.</li></ol> </li> <li>Edit the IISchagent.ini file to configure the debug tools to capture a Web application that stops responding. <ol style="list-style-type: lower-alpha;"> <li>Open Windows Explorer on the cluster controller and move to the C:\IISDebugTools folder.</li> <li>Open the IISchagent.ini file in a text editor such as Notepad. Scroll down to the bottom of the file to find the [HangAgent] section.</li> <li> Modify the file as follows: [HangAgent] Enable=0 LogLocation=c:\iisdebugtools\logs MaxLogFiles=10 WriteLog=1 RequestTimeLimit=240 ActionCommand=c:\iisdebugtools\iisdump.exe MaxActionsAllowed=1 Note the following: <ul> <li>The large dump files will be created in the C:\IISDebugTools\Logs folder. If drive space is limited, the dump files can be redirected to another drive.</li> <li>The value of the RequestTimeLimit parameter is in seconds. Set the value of this parameter to a value that will not cause the debug tools to dump the processes for a typical request that takes longer than the configured time limit. An example of this kind of request is posting lots of data.</li></ul> </li> <li>Change the ActionCommand parameter to the following:

actioncommand=c:\iisdebugtools\iisdump.exe -o :\ 

For example, use the following command:

actioncommand=c:\iisdebugtools\iisdump.exe -o d:\dumpfiles

</li> <li>Make sure of the following: <ul> <li>The destination folder has been created.</li> <li>The LogLocation entry is not changed and appears exactly as shown in the sample code in step c.</li></ul> </li></ol> </li></ol>

The server is now set up to dump the IIS processes when the application stops responding.

After the server is set up
Continue to work with your IIS support professional to resolve the problem.

How to set up the IIS debug tools to capture a Web application that quits unexpectedly (crashes)
This section discusses files that are obtained only from the IIS support professional who requested that you install the debug tools.

Note This article assumes that the %SystemDrive% is the C drive. <ol> <li>Install the IIS debug tools on the cluster controller only. <ol style="list-style-type: lower-alpha;"> <li>Install the tools. Accept the default values during the installation.</li> <li>Do not choose to restart IIS after the installation. You will restart IIS later.</li></ol>

To download the debug tools, visit the following Microsoft Download Center Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en

After the tools are installed, the files are located in the following folder on the server:

%SystemDrive%\IISDebugTools

</li> <li>Edit the Internet Server API (ISAPI) filter in the properties of the WWW Service Master. <ol style="list-style-type: lower-alpha;"> <li>Open the Application Center 2000 MMC.</li> <li>Open Internet Information Services, right-click the server name for the cluster controller, and then click Properties.</li> <li>Click Edit for the WWW Service Master properties.</li> <li>On the ISAPI Filters tab, click the filter that is named IISCrashHangAgent, and then click Edit.

Notice that a red down arrow appears next to the filter. This arrow indicates that the filter is not loaded in memory because you have not restarted the IIS Admin Service yet.</li> <li> Change the following executable path: \\?\C:\IISDebugTools\IISCHAgent.dll Change the previous executable path to the following executable path: C:\IISDebugTools\IISCHAgent.dll </li> <li>Click OK until the master properties dialog box is closed.

Note This change will limit the path length that the tools can work with. However, this limitation is mitigated if you keep the file paths short in the .ini settings. The .ini settings are described earlier in step 8 under the heading &quot;How to set up the IIS debug tools to capture a Web application that stops responding (hangs).&quot;</li></ol> </li> <li>Create a virtual directory to the debug tools folder to replicate the files to the other servers. <ol style="list-style-type: lower-alpha;"> <li>Right-click the Application Center 2000 administrative site, click New, and then click Virtual Directory. The Virtual Directory Creation Wizard starts.</li> <li>Click Next, and then type debug in Alias.</li> <li>Click Next, and then move to the C:\IISDebugTools folder.</li> <li>Click Next two times, and then click Finish to create the virtual directory.</li></ol> </li> <li>Use Windows Explorer to create two folders. <ol style="list-style-type: lower-alpha;"> <li>Open Windows Explorer on the cluster controller and move to the C:\IISDebugTools folder.</li> <li>In C:\IISDebugTools, create a folder that is named Logs, and then create a folder that is named History .</li></ol> </li> <li>Use the Application Center 2000 MMC to exclude from synchronization the folders that you created in the previous step. <ol style="list-style-type: lower-alpha;"> <li>In the left pane, expand the cluster name so that you can see Synchronizations.</li> <li>Right-click Synchronizations, and then click Properties.</li> <li>Add to the list of exclusions the two new folders that you created earlier: C:\IISDebugTools\Logs and C:\IISDebugTools\History.</li></ol> </li> <li>Disable the FailFast registry entry.

The IIS support professional who sent you instructions to set up the servers for the crash dump files will have included some registry files. You will use these registry files to disable the FailFast registry entry. Just double-click the registry file that is named Win2k_DisableFailFast.reg to add these settings to the registry.

Note Use this registry file only after all troubleshooting is completed.</li> <li>Turn off the Debug Exception Catching option.

To make sure that IIS is passing the exception to the debugger correctly, turn off this option in the properties of the Web service. To do so, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>Open the IIS MMC.</li> <li>Right-click the computer name in the left pane, and then click Properties.</li> <li>Click the Edit button for the WWW Service Master properties.</li> <li>On the Home Directory tab, click the Configuration button.</li> <li>On the Process Options tab, clear the Enable Debug Exception Catching check box, and then click OK to close the properties dialog box.</li></ol> </li> <li>Turn on the Leave Running When Idle option.

Important Make sure that the processes that are hosting COM+ components do not shut down by themselves because of inactivity. This shutdown would trigger a false crash dump file. <ol style="list-style-type: lower-alpha;"> <li>Open Component Services. To do so, click Start, click Control Panel, open Administrative Tools, and then double-click Component Services.</li> <li>In the left pane, expand the following series of nodes: Component Services, Computers, My Computer, and COM+Applications</li> <li>For each custom package or Web site or Web directory that is running in Medium or High isolation, follow these steps: <ul> <li>Right-click the item, and then click Properties.</li> <li>On the Advanced tab, select the Leave Running when Idle check box, and then click OK.</li></ul> </li></ol> </li> <li>Reset the IIS Admin Service on each server in the cluster.

You can reset the IIS Admin Service on each server without disrupting production. You can do this from the Application Center 2000 MMC. If you use a third-party load balancing solution instead of network load balancing, set the servers offline by using the load balancer. To do this, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>Drain the current connections for an appropriate time for the applications that are running on the Web site.</li> <li>Set each server offline, one at a time.</li> <li>After the server is offline, restart the IIS service, and then set the server online again.</li></ol>

By repeating this process for each server in the cluster, the Web applications will remain available.</li> <li>Move the IISCrashHangAgent ISAPI to the top of the list. <ol style="list-style-type: lower-alpha;"> <li>Open the Application Center 2000 MMC.</li> <li>Open Internet Information Services, right-click the server name for the cluster controller, and then click Properties.</li> <li>Click Edit for the WWW Service Master properties.</li> <li>On the ISAPI Filters tab, click the filter that is named IISCrashHangAgent.

Notice that a green arrow now indicates that the filter is loaded in memory.</li> <li>Move the filter to the top of the list. To do so, click the Up button.</li> <li>Click OK buttons until the master properties dialog box is closed.</li></ol> </li> <li>Attach the debugger to the IIS processes.

Perform this step from a console session that is running on the server. You can use pcAnywhere. However, avoid using a terminal services session. <ol style="list-style-type: lower-alpha;"> <li>Open a command prompt, and then change directory to the C:\IISDebugTools directory.</li> <li>Run the following command:

iisdump.exe –i

</li></ol> </li></ol>

The server is now set up to dump the IIS processes when the application quits unexpectedly.

After the server is set up
Continue to work with your IIS support professional to resolve the problem.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

<div class="references_section">