Because the ISAPI extension DLL is loaded in the same process as the HTTP server, access violations by ISAPI extensions can crash some HTTP servers. Therefore, you should thoroughly test all ISAPI extensions to ensure integrity. This is important; if your ISAPI extension malfunctions, it can corrupt the server's memory space, or cause memory or resource leaks.
With IIS 4.0 you can make sure that such suspect ISAPI DLLs run in the namespace marked as Run in separate memory space. This will ensure that IIS will use the process isolation technique to execute the ISAPI DLL in a different process than the IIS process. IIS also does detection and recovery for such exterior processes dedicated for hosting ISAPI DLLs.
To avoid this problem, many HTTP servers wrap the entry points for your ISAPI extensions in a try/except clause so access violations or other exceptions will not directly affect the server. For more information on the try/except clause, refer to the Win32® API documentation.
The main entry point in the ISAPI extensions, HttpExtensionProc, takes only one input parameter: a pointer to the structure type EXTENSION_CONTROL_BLOCK. You are not expected to change any member except lpszLogData in the ECB structure.
However, you are encouraged to initialize your DLL automatically by defining an entry point function for the DLL (for example, DllMain). The operating system calls this entry point function by default the first time a LoadLibrary call or the last time a FreeLibrary call is made for that DLL, or when a new 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 PerfMon. You can also use the lpszLogData member of the ECB to record data with the server log.