Because the ISAPI extension DLL is loaded into the same process as IIS, it is possible that access violations and other bugs in the ISAPI extension's code could cause IIS to crash. Therefore, you should thoroughly test all ISAPI extensions to ensure integrity.
With IIS version 4.0 and later, you can make sure that such suspect ISAPI DLLs run in separate processes by placing the extension in an application marked as out-of-process, so that IIS will use the process isolation technique to execute the ISAPI DLL in a different process from that of the main IIS process. IIS also performs crash detection and recovery for such exterior processes.
General state initialization for an ISAPI extension could occur in the entry point function GetExtensionVersion code. Alternatively, state initialization could also occur in the optional DLL entry/exit function—usually DllMain, when using Microsoft Visual C++. Just like any Win32 DLL, if you provide a DLL entry/exit function, it will be called by the C run-time library when the extension is first loaded, when it is released by IIS, and whenever a new thread (other than the primary thread) is created or destroyed in the process.
You are also encouraged to maintain statistical information, or any information pertaining to the DLL, within the DLL itself. By creating the appropriate forms, you can measure the usage and performance of a DLL remotely. Also, you can integrate this information with the system performance counters so that you can integrate it with SysMon. You can also use the lpszLogData member of the EXTENSION_CONTROL_BLOCK structure to record data with the server log.
This documentation set assumes that you are using either C or C++ as your development language, and that you are not making use of the Microsoft Foundation Classes (MFC) library. (The MFC library provides an object model, as well as a wizard, that might aid you in creating ISAPI extensions. Classes such as CHttpServer, CHttpServerContext, and CHtmlStream are provided. For more information on MFC, see the MFC and Visual C++ documentation.)
Because all (in-process) requests will be handled by the same DLL mapped into the IIS process space, your ISAPI extension must be designed and implemented with appropriate thread-safe procedures and structures. This is especially important if your ISAPI extension relies on global state information or structures, such as worker-thread work queues. For an example of how to handle simple thread synchronization in an ISAPI extension, see the sample Keep-Alive with Worker Thread.
Important The operating system serializes calls to the DLL entry/exit function DllMain. Due to potentially troublesome interactions with the thread synchronization used to accomplish this serialization, you should avoid using—or requiring—thread synchronization mechanisms (including the various Win32 WaitFor… functions) within DllMain.
For information on how to write multithread-safe DLLs, refer to the related articles in the Platform SDK, or any of the advanced books on Win32 programming.