Special Considerations for ISAPI Modules
An ISAPI module is a specialized DLL loadable by the Microsoft IIS web server. ISAPI modules are standard Windows DLLs which must be hosted by another process. In IIS, a process named w3wp.exe loads and serves ISAPI DLLs. Each ISAPI DLL inherits privileges and access rights from its host process and can only access folders, files, and other system resources that are accessible by the host process.
Windows assigns a user account to each ISAPI host process which either can be the built-in account named IUSR or any other user account configured by the administrator. A host process is also called an ISAPI pool. An ISAPI pool is a collection of host processes that share the same configuration. Each pool can be configured to run one or more ISAPI applications. See this section for IIS 7.0 to learn how an application is created and configured: https://unigui.com/doc/online_help/iis_7_0.htm
You can share one pool between multiple ISAPI modules, or create a separate application for each ISAPI module and assign separate pools to each application. Applications in the same pool are isolated from applications in other pools, but applications within the same pool are not fully isolated from each other. If one application in a pool becomes unstable, it can affect other applications sharing that pool. If a pool crashes, all applications in that pool become unavailable until the application pool restarts.
uniGUI applications are stateful and keep complex state information in server memory. If the application crashes, active sessions will lose their state information and all connected users will need to log into new sessions when the application pool is back online.
Because uniGUI applications are stateful, deploying them together with unstable ISAPI modules can lead to poor user experience after a crash (lost sessions and forced re-logins). Ensure your uniGUI application is stable before deploying to production, and consider isolating critical applications into separate application pools.