如果Web服务器操作系统是Windows server 2003，则IIS 6.0进程模型是asp.net的默认选择。其名称明确之处，该模型需要IIS 6.0、然后，在windows 2003 的服务器上，仍然可以让asp.net遵守IIS 5.0进程模型的规则。可以通过修改machine.config文件中的<processModel>节，显示的启用该模型。
<processModel enable="true">
当然，我并不建议且滑倒IIS 5.0进程模型，虽然这样做是合法的。主要原因在于:IIS 6.0利用不同的内部模块的管道来处理一个入站请求，并且只有在仿真模式下运行时才能模仿IIS 5.0的行为。IIS 6.0管道以一个名为 完wp.exe的工作进程为中心。所有被分配给同一个应用程序池的Web应用程序共享该可执行进程的一个副本。用IIS 6.0的行话来说，一个应用程序池是一组共享相同的工作进程的副本的Web用用程序。IIS 6.0使我们能够指定应用程序池，以实现Web服务器上托管的各应用程序所需的隔离程度。
w3wp.exe worker进程加载aspn_isapi.dll;该ISAPI扩展又加载通用语言运行库（CLR），并启动ASP.NET运行库管道来处理该请求。当IIS 6.0进程模型正在使用时，内置的ASP.NET工作进程会被禁用。
注意：只有asp.net1.1完全利用IIS 6.0进程模型。如果把asp.net1.0安装到一台windows 2003 机器上，则默认的进程模型是IIS 5.0进程模型。之所以会这样，是因为asp.net1.1所带的aspnet_isapi.dll能够识别它的宿主，并根据需要加载CLR。asp.net1.0所带的aspnet_isapi.dll只能把请求转发给asp.net工作进程，绝对不会加载CLR。
下图为IIS 6.0进程模型
IIS 6.0作为内核级模块实现其HTTP监听程序。因此，所有的输入请求首先由http.sys驱动程序以内核模式进行管理。没有任何的第三方代码会与该监听程序交互，并且没有任何的用户模式冲突会影响IIS的稳定性。http.sys驱动程序监听请求，并把他们投递到合适的应用程序池的请求队列。一个称为饿哦Web管理服务的模块读取IIS 冤苦，并指示http.sys驱动程序创建与元库中所注册应用程序池一样多的请求队列。
总之，在IIS 6.0进程模型下，asp.net运行的更快，因为在inetinfo.exe可执行进程和工作进程之间，不需要任何进程间的通信。http请求直接在托管CLR的工作进程中被交付。此外，asp.net工作进程不是一个特俗进程，它只是IIS工作进程的一个副本。这一事实将进程回收、页面输入缓存和运行状况检查的负担（转交给IIS）