How The Catalog Page Works

">B A C K

View Source

Functional Overview

The Exploration Air/AdventureWorks Catalog page is designed to show how Microsoft Internet Information Server (IIS) 4.0 handles server errors such as misbehaved dynamic-link libraries (DLLs).

Starting with IIS4.0 you can isolate server applications, which means they will be run in a process separate from the Web server process. If an isolated application fails, it won't affect the running of the server (or of other applications, except for those that work as a unit with the failed application). Isolating an application can also be described as running it in a separate memory space.

Generally, it is a good idea to isolate applications; slightly more memory is used, but the server will be less likely to fail if an application fails. There may be some performance degradation while running a Web application in this manner, but, depending on the business scenario, the extra robustness may be more important than performance.

Required Settings

For the ExAir Catalog application to work correctly you must have the following settings on the Catalog directory.

Run in separate memory space: Yes
Enable debug exception catching: No
Enable ASP server-side script debugging: Yes

It is also recommended that you turn off page caching in your browser.

The MoreInfo.asp file calls a component called ProdLookup.ProdLookup.1, which is defined in a DLL in ProdInfo.dll. ProdInfo.dll has the job of creating an Access Violation when the user selects the carabiner, otherwise it returns some data about the product selected. An access violation is a serious error which may cause an application to fail.

Selecting the carabiner causes ProdInfo.dll to create an Access Violation.

A DLL is not a process and as such must run in the address space of another process. Normally, the DLL would run in the IIS process itself, which would mean that the DLL has access to the same memory as IIS and as such could cause IIS to fail. The Exploration Air sample site is an isolated application which means it runs in a separate process to IIS. These processes are always called Mtx.exe because they are controlled by Microsoft Transaction Server.

The following shows how it looks schematically:

Two DLLs - One in-process (inproc) with respect to IIS,
the other out-of-process (OOP) with respect to IIS.

If you look carefully at the picture from Task Manager below, you can see three important processes. The first is Inetinfo.exe itself and two processes called Mtx.exe. The first Mtx.exe (labeled '1') is a process owned by Inetinfo.exe and is internal to IIS. The second Mtx.exe (labeled '2') is the second process started when the Exploration Air site is accessed for the first time. All Active Server Pages and DLLs for Exploration Air are loaded into this one process. If anything should cause a serious error (such as ProdInfo.dll failing) then Microsoft Transaction Server will failfast and shut down the offending process, in this case Mtx.exe. If ProdInfo.dll were running inside of the IIS process Windows NT would shut down IIS.

Windows NT Server Task Manager showing isolated processes.

Note that when the user attempts to load another Exploration Air page, IIS will automatically reload Mtx.exe and load the appropriate DLLs and Active Server Pages, without notifying the user. You can try this by reloading the Catalog.asp file.

Components Used

The page uses the component ProdInfo.dll which is written in C++. It has one method, Details, which returns information about the item in question. As you'll notice from the code, it is all hard-coded data. The intent is not to show data access from C++, but rather to show what happens when a very serious fault occurs in a DLL.