IIS

## The three layers behind one request IIS is not a single process. A request to an IIS-hosted application passes through three distinct pieces before any of your code runs. **HTTP.sys** is a kernel-mode driver that owns the TCP ports. It listens, parses the request line and headers, matches the URL against the set of registered URL prefixes, and places the request into a *request queue*. There is one request queue per application pool. Because HTTP.sys is in the kernel, it can accept connections and even serve cached responses while no user-mode process for that application is running at all. **WAS** — the Windows Process Activation Service — watches those queues. When a request lands in a queue that has no worker process behind it, WAS starts one. The World Wide Web Publishing Service (W3SVC) sits alongside it and owns the HTTP-specific configuration, handing the port and prefix registrations to HTTP.sys. **w3wp.exe** is the worker process. It loads the native IIS modules, loads the CLR if the application is managed, and runs your request pipeline. This is the process you attach a debugger to, the process that shows up in Task Manager eating memory, and the process that dies when your application faults. ## What the pool actually owns The application pool is the configuration object that describes that worker process. Its settings live in `applicationHost.config` under `<applicationPools>`: ```xml <add name="ContosoPool" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated" enable32BitAppOnWin64="false"> <processModel identityType="ApplicationPoolIdentity" idleTimeout="00:20:00" /> <recycling><periodicRestart time="1.05:00:00" /></recycling> </add> ``` The pool decides: the **identity** the code runs as (and therefore every file, share and database it can reach); the **managed pipeline mode**, Integrated or Classic, which decides whether managed modules see every request or only ASP.NET-mapped ones; the **CLR version**, including the value `No Managed Code` used for ASP.NET Core; **bitness**; **recycling** rules and the **idle time-out**; **rapid-fail protection**; and the request **queue length**. ## Sites, applications, and pools are three different things A **site** is a set of bindings (protocol, IP, port, host name) plus a root application. An **application** is a virtual path such as `/shop` mapped to a physical directory, and every application is assigned to exactly one application pool. A **virtual directory** is just a path alias inside an application and has no process of its own. That means the relationship is many-to-many in the useful direction: one site can spread its applications across several pools, and one pool can host applications drawn from several sites. Counting worker processes by counting sites is the classic beginner error. ## One process per pool — with two exceptions By default a running pool has exactly one `w3wp.exe`. Two things change that. A **web garden** (`maxProcesses` greater than 1) runs several workers for the same pool; requests are spread across them, which breaks any in-memory session or cache and is rarely the right answer today. And during an **overlapped recycle** you briefly see two workers for one pool while the new one warms up and the old one drains. To see the mapping live, `appcmd list wp` prints each running worker with its pool, and the worker's own command line carries `-ap "PoolName"`, which is why adding the Command Line column in Task Manager tells you instantly which pool a hungry `w3wp.exe` belongs to. ## Why the boundary is the point Everything in one pool shares one address space. An unhandled exception that takes down the process takes down every application in that pool. A memory-limit recycle triggered by one leaky application discards the in-memory caches and sessions of its neighbours. The identity is shared, so granting one application write access to a folder grants it to all of them. A stuck thread pool starves them all. Conversely, separating applications into their own pools buys real isolation at the cost of memory: each additional worker process carries its own CLR, its own JIT-compiled code and its own caches, typically tens to a couple of hundred megabytes before your application allocates anything. One consequence worth memorising for diagnosis: if a pool is stopped — either manually or by rapid-fail protection after repeated startup failures — HTTP.sys still accepts the connection and answers **503 Service Unavailable**, not 404. A 503 that appears instantly, with nothing at all in the application's own logs, almost always means the request never reached a worker process.