On machines running IIS5 and IIS5.1, these are the Inetinfo.exe, DLLHost.exe and/or ASPNET_WP.exe processes. On machines running IIS 6 or 7, this is the w3wp.exe process.

The following steps will allow us to get log files of the processes hosting the IIS or ASP.NET applications, as well as obtain the thread ID that is using the CPU that will directly correspond to the log file. Please let us know if you have any questions about using this process.

Before the issue occurs

A. Download DebugDiag:

  1. Install the Debug Diagnostic tool
  2. The default installation location for the package is C:\Program Files\IIS Resources\DebugDiag. It can be changed.
  3. Make sure any other monitoring and debugging tools are not running.

B. Create a Performance Monitor log:

  1. In Performance Monitor, expand Performance Logs and Alerts
  2. Right Click on Counter Logs
  3. Choose New Log Settings...
  4. Enter a descriptive name
  5. Note the log file location for later (or go to the Log Files tab and change the location)
  6. Click the Add Counters button
  7. Click the All Counters radio button.  Click the Select instances from list radio button, and select the process hosting the IIS or ASP.net application.  On Windows 2000 and Windows XP, this will be inetinfo, dllhost, or aspnet_wp .  On Windows 2003 and Windows 2008 this will be w3wp.  NOTE: It is possible you will see multiple instances of dllhost on IIS5/5.1 or w3wp on IIS6/IIS7 in the list of available processes.  If you do, or if you are unsure of which process to monitor, please cltrl-click to multiselect all of the available IIS/ASP.net choices.
  8. If the application is not an ASP.net application, select the following from the Performance Object dropdown, being sure to Add each one as you select it:
    • Process
    • Thread

    If the application is an ASP.net application, select the following from the Performance Object dropdown, being sure to Add each one as you select it:

    • Process
    • Thread
    • .NET CLR Data
    • .NET CLR Exceptions
    • .NET CLR Interop
    • .NET CLR Jit
    • .NET CLR Loading
    • .NET CLR LocksAndThreads
    • .NET CLR Memory
    • .NET CLR Networking
    • .NET CLR Remoting
    • .NET CLR Security
    • ASP.NET
    • ASP.NET Applications
  9. Click Close
  10. Click OK

For the ASP.NET counters, select the version that you are wanting to monitor.  Ex.  For 1.1 framework, select ASP.NET v1.1.4322 and ASP.NET Applications v1.1.4322.

IMPORTANT: The Data Sampling Interval and time to start monitoring is subjective to when the CPU spike reproduces. Due to the log size, monitor the server to gather the needed data while not overwhelming the server.

Note: For more information on Performance monitor, see http://support.microsoft.com/?id=248345

After the issue occurs

A. Let the process run
Now let the server run for a few minutes to document the environment in which the high CPU/hang is occurring in.

B. Capture the memory Dumps

  1. Launch DebugDiag
    • Start, Program Files, IIS Diagnostics, Debug Diagnostics, Debug Diagnostic Tool
  2. From the Tools menu, select Create IIS Hang Dump

Repeat Step 2 every 1 - 2 minutes until you have 3 sets of memory dumps. Make sure the previous memory dumps completed before continuing to capture the next set of memory dumps. The multiple memory dumps will allow us to see if the process is progressing during the hang/high CPU symptoms or whether the process is actually performing work.

Files will be created in the following path by default:
C:\Program Files\IIS Resources\DebugDiag\Logs\Misc

C. Stop the Performance Monitor log

In Performance Monitor:

  1. Right click on your log that is now listed under Counter Logs
  2. Choose Stop Log

kick it on DotNetKicks.com