应用运行在同一个上下文上并共享他们所有的数据。值得一提，asp.net引入APPDomain概念，本质上是一种提供独立和安全边界的受管制轻量级进程。每个IIS虚拟目录在一个APPDomain里执行，他将自动加载到工作进程只要资源是属于第一次请求的应用程序。一旦appdomain被加载，换句话说，当前请求所有需要的程序集被加载到appdomain–实际上是传递到asp.net管道处理。若干appdomains能够这样运行在同样的进程中，当多个请求对于同样的appdomain能够在多个线程出来。尽管如此，一个线程并不属于一个appdomain，他能为多个不同的appdomians处理多个请求,但是同一个给定的时间一个线程属于一个APPdomain.

　　处于性能目的，工作线程能够根据一些标准（通过MACHINCE.CONFIG文件配置）被回收。这些标准包括进程生命周期，请求以及队列数量，空闲时间，内存分配。一旦达到这些参数中一项临界值，ISAPI扩展将生成一个新的工作进程实例用来处理请求。实际上，先前的进程实例并没有被关闭，但是他被终止服务等待的请求。

IIS6.0处理模型

　　IIS6是WINDOWS2003系统默认的。在IIS5处理模型的上他有几个改变和改进。其中之一最大改变就是应用程序池概念。在IIS5系列应用程序上，即所有的appDomains—运行在asp.net工作进程上。为了在安全以及特性上完成一个出色的界定，IIS6处理模型允许应用程序运行在同一个工作进程的不同拷贝上。每个应用程序池能够包含多个appdomains（运行在单独一个工作进程拷贝上).换而言之，这个变化是从单一进程运行所有程序到多个进程运行每一个应用池。这个模型也叫做工作过程隔离模式。

　　例外一个大变化相对先前的模型在IIS监听所有传入数据方面。在IIS5里，由IIS进程,inetinfo.exe监听指定的TCP端口。在IIS6中，传入请求被处理并队列在核心级别来替换先前通过核心驱动调用http.sys的用户模式；这种方法有几个优势相对于先前的模式被叫作 kernel-level 请求队列。

　　一旦一个请求到达核心级别设备驱动http.sys，然后发送到相应的应用程序池队列，每个队列属于一个指定的应用程序池。

　　工作进程负责加载asp.net ISAPI扩展，依次加载 CRL 委派所有工作到HTTP运行时。

　　W3WP.exe进程与IIS5下面的aspnet_wp.exe不同，他不是asp.net特有的，能够用来处理任何类型的请求。什么样的ISAPI模块被加载类型根据需要的服务资源类型。