IIS 5.0 Application Isolation in Windows 2000

In Microsoft Windows 2000, Internet Information Services (IIS) 5.0 isolates web applications by decoupling application execution from the core web server process using Component Services (COM+). By utilizing dedicated surrogate processes (dllhost.exe), IIS 5.0 offers three distinct protection levels—Low, Medium, and High—to prevent application faults, memory leaks, and fatal crashes from taking down the main web service or neighboring applications.

The Role of Inetinfo.exe and COM+

In IIS 5.0, the core web service runs inside the main executable named inetinfo.exe. This process handles core functions such as HTTP listening, file mapping, and connection management. To provide stability without sacrificing flexibility, Windows 2000 integrates IIS with COM+ (the successor to Microsoft Transaction Server). COM+ serves as the process orchestrator, spinning up dllhost.exe instances to act as external worker containers for Active Server Pages (ASP) scripts, ISAPI extensions, and web components.

Application Protection Levels

Windows 2000 allows administrators to configure process isolation on a per-application basis through the Internet Services Manager (ISM) console. Three isolation levels dictate where application code executes:

1. Low (In-Process)

  • Execution Location: Inside the core inetinfo.exe process.
  • Behavior: The application shares the memory space, threads, and resources of the web server engine.
  • Trade-offs: This configuration offers the fastest performance because it eliminates inter-process communication (IPC) overhead. However, it provides zero isolation; an unhandled exception, bad pointer, or memory leak within the application can terminate inetinfo.exe, crashing the entire web server and all hosted sites.

2. Medium (Pooled / Out-of-Process)

  • Execution Location: Inside a shared dllhost.exe process distinct from inetinfo.exe.
  • Behavior: This is the default setting in Windows 2000. All applications configured with Medium isolation share a single, common surrogate process known as the "IIS Out-Of-Process Pooled Applications" package.
  • Trade-offs: If a pooled application crashes, inetinfo.exe remains operational, ensuring the web server itself stays online. However, a failure in one pooled application can terminate the shared dllhost.exe, disrupting other applications running in that same pool.

3. High (Isolated / Out-of-Process)

  • Execution Location: Inside a dedicated, unique dllhost.exe instance.
  • Behavior: The application receives its own isolated COM+ package. It does not share a process boundary with inetinfo.exe or any other web application.
  • Trade-offs: High isolation provides maximum fault tolerance and security. A fatal error strictly crashes that specific application's dllhost.exe container. The trade-off is increased memory consumption and system overhead, as running numerous separate dllhost.exe processes requires significant system resources.

Process Communication and Crash Recovery

When an HTTP request targets an out-of-process application (Medium or High):

  1. inetinfo.exe receives the incoming request via TCP/IP.
  2. The request is marshaled across process boundaries via standard COM+ Inter-Process Communication (IPC) to the appropriate dllhost.exe.
  3. The application executes the script or binary, and the response is marshaled back to inetinfo.exe to be sent to the client browser.

If an application crashes, Windows 2000 and COM+ terminate only the affected dllhost.exe. The core inetinfo.exe detects the broken connection, returns a 500 Internal Server Error to the client, and automatically reinitializes a new dllhost.exe instance upon the next incoming request without requiring a manual restart of the World Wide Web Publishing Service.