ASP.Net Process Model (IIS 6.0)

One of the most important requirements for .NET Framework applications is reliability. An architecture in which applications run inside the server process (in IIS, Inetinfo.exe) does not produce a solid foundation for building reliable applications that can continue to run over a long period of time. Too many resources are shared on the process level, and it is too easy for an error to bring down the entire server process.

To solve this problem, ASP.NET provides an out-of-process execution model, Aspnet_wp.exe, which helps protect the server process from user code. It also enables you to apply heuristics to the lifetime of the process to improve the availability of your Web applications. Using asynchronous interprocess communication helps provide a balance between performance, scalability, and reliability.

Process model settings are exposed in the root configuration file for the computer, Machine.config. The configuration section is named Element and is shown in the following example. On computers running Windows 2000 and Windows XP, the process model is enabled by default (enable="true").

One of the most important requirements for .NET Framework applications is reliability. An architecture in which applications run inside the server process (in IIS, Inetinfo.exe) does not produce a solid foundation for building reliable applications that can continue to run over a long period of time. Too many resources are shared on the process level, and it is too easy for an error to bring down the entire server process.

To solve this problem, ASP.NET provides an out-of-process execution model, Aspnet_wp.exe, which helps protect the server process from user code. It also enables you to apply heuristics to the lifetime of the process to improve the availability of your Web applications. Using asynchronous interprocess communication helps provide a balance between performance, scalability, and reliability.

Process model settings are exposed in the root configuration file for the computer, Machine.config. The configuration section is named Element and is shown in the following example. On computers running Windows 2000 and Windows XP, the process model is enabled by default (enable="true").

<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="false"
cpuMask="0xffffffff"
userName="machine"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseRestartDeadlockInterval="00:09:00"
responseDeadlockInterval="00:03:00"
maxWorkerThreads="20"
maxIoThreads="20"
/>

Most of configuration settings in this example help control when a new worker process begins to serve requests (gracefully taking the place of an old worker process). The userName and password attributes define the account under which the ASP.NET worker process runs. These default to the values machine and autogenerate, respectively. These values tell ASP.NET to use the built-in ASPNET account and to use a cryptographically strong random password stored in the Local Security Authority (LSA) for that account.

On computers running Windows Server 2003, by default ASP.NET runs as part of the IIS 6.0 (W3wp.exe) process using the default identity NETWORK SERVICE. If IIS 5 isolation mode is configured on a computer running Windows Server 2003, the ASP.NET worker process runs in the ASPNET account.

If you want a more privileged process, you can set the userName attribute to System, which causes the ASP.NET worker process to run with the same identity as the Inetinfo.exe process. This process runs by default as the System identity. When so configured, the ASP.NET worker process will have the right to access nearly all resources on the local server. In Windows 2000, Windows XP, and Windows Server 2003 family systems, the System account also has network credentials and can access network resources as the machine account.

Changing the userName attribute to System enables access to and the ability to alter nearly all the resources on the computer, creating a significant security risk to your server.

The process model supports two types of recycling: reactive and proactive.

Reactive process recycling:
Reactive process recycling occurs when a process is not functioning properly or is unable to serve requests. The process typically displays detectable symptoms, such as deadlocks, access violations, memory leaks, and so on, in order to trigger a process recycle. You can help control the conditions that cause a process restart by using the requestQueueLimit, memoryLimit, and shutdownTimeout configuration attributes. For more information about these attributes, see the Element configuration section.

Proactive process recycling:
Proactive process recycling restarts the worker process periodically even if the process is healthy. This can be a useful way to prevent denials of service due to conditions the process model is unable to detect. A process can be restarted after a specific number of requests or after a time-out period has elapsed. You can enable proactive process recycling using the timeout, idleTimeout, and requestLimit configuration attributes. For more information, see the
Element configuration section.

Reference