Working with IIS worker process isolation mode by Brien M. Posey

Worker process isolation mode provides an easy way to insulate Web applications from each other, so that problems with one Web application don't impact the other Web applications on Microsoft Internet Information Services (IIS).

IIS 6.0 allows you to organize applications into application pools. Each application pool is a completely independent entity, served by one or more worker processes. Usually, a Windows administrator will create a separate application pool for each Web application that the server hosts -- but a single application pool can host multiple applications.

Of course, this raises the question of how application pools can isolate IIS Web applications from each other. True isolation is possible because Windows differentiates between code that is running in kernel mode vs. code that is running in user mode.

Windows runs core IIS components, such as HTTP.SYS and the WWW service, in kernel mode. Each application pool contains its own kernel-mode queue. This means that HTTP.SYS is able to route inbound requests directly to a queue that is dedicated to a specific application pool, all within kernel mode. Application pools are separated from each other by process boundaries.

Worker processes are dedicated to a specific application pool to actually service requests. If a failure occurs, it usually happens within a worker process. However, since worker processes are bound to particular application pools, a worker process failure will only affect the application in which it resides, but no others.

The really cool part is that IIS provides mechanisms for monitoring the health of a worker process. If a worker process fails, the process can be restarted without the end user even being aware of the failure.

This is possible for two reasons:

• Application pools are not limited to using a single-worker process. If an application pool is configured to use multiple worker processes, then the failure of one worker processes does not affect the other worker processes within the application pool. The other worker processes continue hosting the application.
• Worker processes are not directly linked to inbound requests. For example, if a Web site had only one worker process and it failed, HTTP.SYS would continue to send requests to the application pool's dedicated queue. Without the worker process being operational, the queued requests can't be serviced, but the server is not flat out rejecting the requests either.

If Internet Information Services detects that a worker process has failed, it will simply restart the worker process (this is known as recycling). The entire process usually occurs within seconds, and then the worker process begins processing the queued requests once again.

In addition, to isolating worker processes from each other, the Internet Information Services architecture provides options for further limiting the effects of worker processes on the rest of the system. There are options for binding worker processes to specific processors on servers with multiple CPUs. You can also limit the amount of memory that worker processes consume.

IIS Important Users/Groups

1. Users:- It creates the following users:

• IWAM_Computername
• IUSR_Computername
• ASPNET
• Certificate Publishers
  

1. Groups: - IIS_WPG - It has the following users

• IUSR_Computername
• IWAM_Computername
• networkservice
• localservice
• system

Backup/Restore IIS Configuration and Re-Installning IIS

Backup the config

• Go to inetmgr-actions-all tasks-backup

To remove iis

• net stop iisadmin /y
• Go to services.msc- check service dependencies-stop those
• appwiz.cpl (Add/Remove)- Windows Components- Application Server-uncheck IIS
• Check if users have been removed-lusrmgr.msc-IUSR_Computername & IWAM_Computername
• Verify that the Inetsrv folder has been deleted. By default, the Inetsrv folder is located in the %Windir%\System32 folder.

Debugging windows

• Debugging windows

1. Download Windbg

Debuggin IIS crashes/hangs

• Download the IIS Debug Toolkit

• 	Use the GUI or the command line to enable Pageheap.exe: • To use the GUI, follow these steps: a. Run Gflags.exe. b. For Image File Name, type the name of the process that you want to debug. For an IIS 5.0 Web site, the name of this process is Inetinfo.exe, Dllhost.exe, or Aspnet_wp.exe. For an IIS 6.0 Web site, the name of this process is Inetinfo.exe or W3wp.exe. c. Under Destination, click the Image File Options option. d. In the lower pane of the Global Flags dialog box, click Enable page heap. e. Click Apply, and then click OK. • To use the command line, follow these steps: a. Switch to the folder where the IIS Crash/Hang Agent is installed. b. Run the following command: gflags –p /enable Process Name NoteFor IIS 5.0, Process Name is Inetinfo.exe, Dllhost.exe, or Aspnet_wp.exe. For IIS 6.0, Process Name is Inetinfo.exe or W3wp.exe.
  3.	If the targeted process is Inetinfo.exe, use the Iisreset command to restart IIS. To do this, follow these steps: a. Click Start, click Run, type Cmd, and then click OK. b. At the command prompt, type Iisreset computername /restart, and then press ENTER. Replace computername with the name of your IIS server. If the targeted process is Dllhost.exe or Aspnet_wp.exe, unload and then reload the Web application (you do not have to restart IIS).
  4.	Attach the debugger to the targeted process: a. Switch to the folder where you installed the IIS Crash/Hang Agent and the IISDump tools. b. At a command prompt, run the following command: iisdump.exe –I –p [PID of Targeted process]

  When the corruption occurs, a breakpoint exception dump file or a second chance access violation dump file is created. You must use the Windows debugger (Cdb.exe or Windbg.exe) to analyze the dump file so that you find the cause of the corruption.
  
  Remember that in certain circumstances, Pageheap.exe may not help find the cause of the corruption when Pageheap.exe is running in NORMAL mode. If this occurs, run Pageheap.exe in FULL mode.
  
  When you complete the debugging, you can disable Pageheap.exe. To do this, either click to clear the Enable Pageheap check box in the Gflags GUI, or run the following command at a command prompt:
  gflags –p /disable Process Name
  Note For IIS 5.0, Process Name is Inetinfo.exe, Dllhost.exe, or Aspnet_wp.exe. For IIS 6.0, Process Name is Inetinfo.exe or W3wp.exe.
  
  Note Running Gflags with the –p switch is the same as running Pageheap.exe. For example, both of the following commands cause Pageheap.exe to run in NORMAL mode for the Inetinfo.exe process:

  •	Gflags –p /enable inetinfo.exe
  •	Pageheap.exe /enable inetinfo.exe