IIS Service Startup

Applies To: Windows Server 2003, Windows Server 2003 with SP1

On rare occasions, you might encounter problems related to starting the IIS services infrastructure. The IIS services are generally robust enough to handle problems and recover from them gracefully. If a problem does occur and if it is appropriate, an event is logged to the application/system event log explaining the failure. Typically, the startup process never needs troubleshooting beyond examining messages written to the event log and taking the required corrective action. However, because it is helpful to understand the inner workings of an application in order to recognize problematic behavior, this section describes the major stages of the IIS services infrastructure startup process.

For information about the components of the services infrastructure, see IIS 6.0 Architecture.

The Windows Service Control Manager (SCM) performs Windows operating system service management operations. Among other things, SCM is responsible for signaling services to begin the startup process and for managing service dependencies. Some services are configured to auto-start, which means that SCM asks those services to start when the system is restarted. Other services are configured to manually start (or demand-start), which means that SCM starts those services only when prompted by an external request or when a service dependency demands it.

IIS services startup begins when the computer restarts. The IIS Admin service, which is hosted by Inetinfo.exe, is configured as an auto-start service. This is the first service in the IIS service infrastructure that is asked by SCM to start. The IIS Admin service depends upon the Remote Procedure Call (RPCSS) service and the Security Accounts Manager (SAMSS) service, which means that SCM guarantees that these are started before the IIS Admin service.

The next auto-start service in the IIS services infrastructure that starts is the World Wide Web Publishing Service (WWW service). It is hosted by Svchost.exe. In addition to the IIS Admin and RPCSS services, the WWW service has dependencies on the HTTP SSL (HTTPFilter) service. The IIS Admin service and RPCSS were started earlier, but before SCM starts the WWW service, it needs to demand-start the HTTPFilter service.

The HTTPFilter service has dependencies on the IIS Admin service and the HTTP service. It is this dependency on HTTP that causes SCM to start the HTTP.sys kernel-mode driver. Consequently, SCM starts the HTTPFilter service, which runs in Lsass.exe (or Inetinfo.exe if you are running in IIS 5.0 isolation mode), and then starts the WWW service.

The following sections describe what happens when these services start.

HTTP.sys

In IIS 6.0, unlike in earlier versions of IIS, the HTTP.sys kernel-mode device driver is not part of the core IIS services. In Windows Server 2003, the HTTP.sys driver actually exposes an API set that any application or service, not just IIS, can leverage. However, since IIS 6.0 is the major client, so to speak, of HTTP.sys, it is beneficial to understand how HTTP.sys relates to IIS 6.0.

The primary responsibility of HTTP.sys is to listen for and respond to HTTP requests on the network endpoints on which it is requested to do so. When HTTP.sys starts, by default it listens for HTTP requests on all IP addresses configured on the system. In some cases, though, it is beneficial for HTTP.sys to listen only on specific addresses — for example, if Windows Media Services needs to listen on port 80 of a specific IP address, outside of the HTTP.sys driver. To accommodate this need, HTTP.sys has an IP inclusion list. This list, when it contains entries, tells HTTP.sys which IP addresses to listen on, and, thereby, which IP addresses not to listen on. At startup, HTTP.sys examines this list and configures itself accordingly. As a result, changes to this list take effect only when the service is restarted.

IIS Admin Service

The IIS Admin service primarily is responsible for managing the IIS metabase. During startup, it reads the MetaBase.xml file and creates its in-memory representation. Because the IIS Admin service creates this in-memory snapshot, if the metabase file is corrupt or if the XML code in the file is not syntactically well-formed, the IIS Admin service will fail to start. The IIS Admin service is responsible for synchronizing access to the metabase through the various control interfaces, even when manual updates are made directly to the MetaBase.xml file. During startup, the IIS Admin service sets up the control interfaces, like IMSAdmin, and registers for necessary file change notifications from the Windows Server 2003 operating system in order to monitor changes to the XML file.

WWW Service

The WWW service recognizes the following entities:

• URLs. The combined application and site binding information.

• Applications. Unique URLs that, when merged with a sites bindings and endpoints, provide full mapping information that enables HTTP.sys to determine which application pool requests that application should be directed to, and the metadata that should be used to support them.

• Sites. The specific bindings and endpoints that HTTP.sys should listen to. Sites contain one or more applications.

• Application pools. Sets of applications that are routed to the same set of worker processes. Application pools are also a common configuration for the worker processes that serve the applications in the pool.

• Application root. Also known as the Web application starting point, an application root is designated when you create and configure an application on a node in a Web site directory structure. You can have more than one application per Web site. The root of a newly created Web site, including the default Web site that is created when you install IIS, is an application starting point. Every file and directory beneath the starting-point directory in your Web site is considered part of the application until another starting-point directory is found. Thus, directory boundaries define the scope of an application.

When the WWW service starts, it performs the following operations:

1. Reads WWW Service configuration information from the IIS Admin service. This information includes global data, application pool data, Web site data, and application data.

2. Validates this data and logs any errors to the event log, choosing to ignore a record or to alter properties in the record to the defaults.

3. Configures HTTP.sys for all sites, applications, and application pools that are registered, and starts the ones that are set to start automatically.

4. Enables HTTP.sys configuration all at once, allowing IIS to accept requests.

5. If IIS 5.0 isolation mode is enabled, starts a worker process in Inetinfo.exe and waits for the worker process to start.

At this point, IIS can accept incoming HTTP requests. The first HTTP request to an application pool launches the worker process (W3wp.exe). In other words, an application pool can be started even though a worker process is not running.

Worker Process Startup

The fundamental aspects of a worker process startup routine are fairly straightforward. The worker process typically does the following:

1. Starts the metabase listener and listens for change notifications.

2. Initializes the IIS thread pool.

3. Obtains the application pool, which was specified in the command-line parameters, and then sets up the communication mechanism that it will use to receive requests from HTTP.sys.

4. Sets up communication with the WWW service to enable pinging and recycling.

5. Initializes other internal caches and structures that are used to process HTTP requests.

6. Initializes the Web service extension restriction list.

7. Begins accepting requests from HTTP.sys.