Pooled Out-of-Process Model for ISAPI

A new pooled application protection model has been introduced and is the default for new applications and virtual directories created under IIS 5.0. This new model combines a number of key benefits of the IIS 4.0 in-process and out-of-process models. Specifically, the pooled model has superior scalability to the out-of-process model, because there is a single process that hosts pooled extensions. It also has superior protection for the server versus in-process, because ISAPI extensions in the pooled process cannot crash the Web server.

Note   This change does not affect existing virtual directories and applications when the server is upgraded to IIS 5.0, only new ones created after IIS 5.0 is installed.

Note   Any ISAPI extension that is also installed as a filter will automatically load in-process regardless of the properties of the application namespace associated with the extension. The result is that filter and extension combinations behave as if the extension were listed in the InProcessIsapiApps metabase key.

There are a number of conditions that may cause failures for certain ISAPI filters and extensions:

• If you need to debug your ISAPI filter or extension in the pool, you will need to attach to the dllhost instance that is hosting it.
• If your ISAPI filter or extension calls any form of RevertToSelf, then your thread will be running as the WAM user (IWAM_machinename) for pooled applications. The WAM user does not have many of the capabilities of the local system account, and privileged calls that rely on the local system account after reverting will fail.
• If your ISAPI filter or extension uses a thread pool and creates its worker threads from either HttpExtensionProc or DllMain, the resulting worker threads will not be able to adjust the token associated with them. As a result, any calls to APIs such as RevertToSelf, ImpersonateLoggedOnUser, and SetThreadToken will fail when called from the worker thread. You can work around this problem by calling RevertToSelf immediately before creating the worker threads.

If your ISAPI filter or extension falls into one of the above categories and cannot be made to run in the pool, then you can still configure it to run in-process in one of the following two ways:

• You can still create in-process applications. To do this, create the new application virtual directory or server and open its property sheets. On the Home Directory, Virtual Directory, or Directory property sheet, under Application Settings, select Low (IIS Process).
• You can add your extension to the InProcessIsapiApps list in the metabase. This list contains the full paths to any extensions that need to run in-process. Any extensions on this list will be run in-process regardless of the application configuration for the application contains them. There is no user interface for this list, so you will need to use a command-line tool, such as mdutil, to add your extension to the list. The full path of the metabase key is /LM/W3SVC/InProcessIsapiApps.