INFO: COM Servers Activation and NT Windows Stations

1. The security identity under which the COM class is set to start. The identity of a class can be set via the DCOMCNFG tool and is specified by the RunAs named value under the AppID key for the class.
2. Single-use vs multiple-use registration by class objects.
3. The Security Identifier(SID) of the client process (this is the numeric value that represents a particular user account/security identity/principal in a Windows NT environment).
4. The Logon Identifier (LUID) of the client process.(A new logon identifier is generated for each unique logon to a computer running Windows NT. This logon could be either through a user typing in a user name and password at the NT logon prompt, or through a call to the win32 API LogonUser.)
5. Local vs remote activation.
6. The window station of the client.

Back to the top

Multiple-use Classes

1. "Interactive user" security identity. In the case where a multiple-use COM class's AppID is configured to run as the "Interactive User" identity, the very first server process and its class object will be used by COM to service all subsequent activation requests. This server instance will have the interactive window station, if one exists (if no user is logged on locally then all activation requests will fail). As noted above, if a process not launched by COM and not running in the interactive window station registers the CLSID, that registration will fail. And, if an activation request later arrives, a new process will be launched with the security context of the Interactive User. This behavior prevents illicit spoofing of class objects. Since no additional server processes are ever started by COM, the question of new window stations is moot. The SID of the client, its LUID or whether it is local or remote does not matter in this case.
2. "This user" security identity. Similarly, if a multiple-use COM class's AppID is configured to run as "this user" (a predefined security ID), the first server process and its class object will be used by COM to service all subsequent activation requests. This first server instance will have its own window station created as part of the first process creation. Since no additional server processes are ever started by COM, the question of additional window stations is moot. The SID of the client, its LUID or whether it is local or remote does not matter in this case. Note that a new window station will be created when you launch the first instance of a class/AppID configured to run as "This user," even if the same user is currently logged on in the interactive winstation. COM never uses the interactive winstation to launch a server configured to run as "This user" because that would result in different behavior for the class depending upon the unrelated issue of the identity of the currently logged on user. As noted above, if a process not launched by COM and not running in the account specified in "This user" attempts to register the CLSID, that registration will fail and if an activation request later arrives a new process will be launched in the "This user" account. This behavior prevents illicit spoofing of class objects. On the other hand, if the process registered for a given CLSID/APPID is configured to run as "This user," is created in the appropriate user account by some agent other than COM (for example, it is run by the interactive user when the interactive user is the same user as "This user" or it is started via CreateProcess() by a service running in the same security context as "this user"), and it then registers its REGCLS_MULTIPLEUSE class objects, COM will use the existing running class object to satisfy subsequent incoming activation requests from any client.
3. "Launching user" security identity. In this case, the class's AppID is set to launch under the "Launching User" idenitity (this is also known as an "Activate as Activator" class). a. Local client. First consider the local machine case. There are two rules: 1. Each different activation client SID will cause COM to launch a new instance of the server process even in the same window station. 2. Even for matching SIDs (such as the case where the same user is logged on more than once to a single NT machine), each different local client window station will cause COM to launch a new instance of the server process. In other words, launching user identity multiple-use servers are never shared across window stations. All client processes with the same SID and same window stations will share a single server process in the same window station. Since the server shares the window station of the client no new window stations are created. For example, assume that you are interactively logged on as a_domain\a_user. You run multiple instances of the client, all of which will connect to the same instance of the server(which has the interactive window station). Now let's say you have a client, which is a service, that is set to launch start under a_domain\a_user. This service will launch a new instance of the COM server. This happens because COM will cause a new instance of the server to be launched since the service process has a window station other than the interactive window station--even though the identity of the service(client) process is the same as the identity of the running server process (a_domain\a_user). However, note that no new window station is created for the COM server process. The server will still inherit the window station of the service. If the service is set to start under LocalSystem and to interact with the desktop (refer to "Allow Service to Interact with Desktop" check box in the Service applet in control panel), then the service will run in the interactive window station or winsta0. In this case COM will still start a new instance of the server (client's SID which is LocalSystem in this case is different from that of the server's SID which is a_domain\a_user)in the interactive window station. b. Remote client. In the case of remote activation, COM ignores the window station of the client because the client is remote, unlike the local case above. The rule here is that each new client SID will cause a new instance of the server process to be launched and each new server process will get a new window station. Subsequent activation requests by remote clients with the same SID will reuse the existing registered class object as well as its process and window station. For example, assume that you are logged on as a_domain\a_user on 10 different machines. The clients from all these machines will connect to the same instance of the server on the server machine. A client from a a_domain\b_user machine will launch a new server instance and a new window station. Remote callers with the same SID as a local user that has launched the COM server registered for the requested CLSID will reuse the existing class object. However, the order in which the COM server is started is important in this case. If the server is launched by the local client first, then the remote client with the same SID will connect to this server. On the other hand, if the server is launched by the remote client first, then a local client with the same SID will start a new instance of the server. This goes back to the window station rules mentioned above. For local clients, the window station of the client and the server must match, for remote clients the window station of the client is ignored. For example, if local client a_domain\a_user launches the server first, then remote client a_domain\a_user will connect to the server. Conversely, if remote client a_domain\a_user launches the server first, then local client a_domain\a_user will launch a new server instance and a new window station. The LUID of the client does not matter in this case.
4. Service-based COM servers. A COM class/AppID that is packaged in a Win32 service is by practical necessity a multiple-use server since services can be launched only once. In this case, at the first activation request a new process is launched in its own window station. There are two exceptions to this: a. If the service is set to launch under the LocalSystem account, it will inherit a system pre-defined window station. b. If the service is set to launch under the LocalSystem account and can interact with the desktop, it will inherit the interactive window station or winsta0. All subsequent activation requests, whether local or remote, are handled by the service's class object. As noted above, if a process not launched by COM and not running as the specified service registers the CLSID, that registration will fail and if an activation request later arrives the registered service will be launched. This behavior prevents illicit spoofing of class objects.

Back to the top

Single-Use Classes

1. "Interactive user" security identity. Take the case in which the single-use class is set via its AppID to start under the "Interactive User" identity. For this case, each new instance of the server process will always share the interactive window station, if one exists (if no user is logged on locally then all activation requests will fail). No new window station will be created by COM.
2. "This user" security identity. Now consider the case where the single-use COM class's AppId is set to run under the "This User" identity. In this case, the rule is very simple. Every new client activation launches a new process in a new window station. This is true regardless of whether the user specified as "This User" is logged on to the interactive window station at the time of any of the activation requests.
3. "Launching user" security identity. a. Local client. In the local machine activation scenario, the server process will always get the window station of the client. No new window stations are ever created. For example, assume that you are interactively logged on as a_domain\a_user and you run multiple instances of the client program. Each new resulting instance of the server will get the interactive window station. Now assume that the client is a service running under the local system account. The COM server in this case will share the window station of the service process. b. Remote client. In the remote activation case, COM ignores the window station of the client since the client is remote. As always, a new server instance process will be started for each remote activation. The rules are: 1. For each new remote client SID, a new window station will be created for the server process. 2. For each new remote client LUID, a new window station will be created for the server process. 3. All remote clients with the same SID/LUID pair will create servers that will share the same window station. For example, you are logged on the remote client machine as a_domain\a_user. This client launches the remote server that will get a new window station. Now, if a_domain\a_user starts a second instance of the client application from the same client machine which in turn launches a new copy of the server on the remote machine, this server will share the original server's window station. Now assume you log on to another machine again as a_domain\a_user, and run the client from there. The corresponding server instance will have a new window station. This demonstrates that even if the client SIDs are the same, since the second client has a different LUID, its server process will get a new window station.
4. Service-based COM servers. Single-use classes should never be implemented as Windows NT services. It makes no sense, because it is not possible to run multiple instances of an Windows NT service process.

Back to the top

Table Summarizing Scenarios

       |                      Multiple-Use Server
       |             (class factory has requested reuse)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				

Local  | Process launched  | Process        | Process         | Service
       | in the            | launched in a  | launched client | started on
       | interactive window| new window     | window station  | first
       | station on first  | station on     | on first        | activation
       | activation        | first          | request,        | request
       | request,          | activation     | subsequent      | (new winsta
       | subsequent        | request,       | requests from   | or system/ 
       | requests get      | subsequent     | the same SID/   | interactive
       | existing class    | requests get   | window station  | winsta
       | object,           | existing class | get existing    | depending
       | activations fail  | object         | class object, no| on service
       | if no user logged |                | sharing of class| config),
       | on locally        |                | objects across  | subsequent
       |                   |                | window stations | requests
       |                   |                | even if same SID| get
-------|                   |                |-----------------| existing
Remote |                   |                | Process launched| class
       |                   |                | in new winsta on| objects
       |                   |                | first activation|
       |                   |                | request by a    |
       |                   |                | SID, subsequent |
       |                   |                | remote requests |
       |                   |                | by the same SID |
       |                   |                | get existing    |
       |                   |                | class object;   |
       |                   |                | class launched  |
       |                   |                | by local user   |
       |                   |                | reused by remote|
       |                   |                | callers with    |
       |                   |                | same SID        |
				

       |                      Single-Use Server
       |          (new process created for each activation request)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				

Local  | Process always    | Process always | Process always  | N/A(only
       | launched in the   | launched in a  | launched in     | one
       | interactive       | new window     | the window      | activation
       | window station,   | station        | station of      | possible)
       | if no interactive |                | client process  |
       | window station    |                |                 |
       | activation fails  |                |                 |
-------|                   |                |-----------------|
Remote |                   |                | if both SID and |
       |                   |                | LUID of the     |
       |                   |                | client match    |
       |                   |                | previous client |
       |                   |                | activation,     |
       |                   |                | process launched|
       |                   |                | in existing     |
       |                   |                | window station, |
       |                   |                | otherwise in new|
       |                   |                | windowstation   |
				

Back to the top

Window Stations and Windows NT Resources

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
				

Back to the top