There is still a problem here to have a lot of COM developers. Last spring, a company was burst with me, and their developers built a distributed application using COM, where the client process runs on the network workstation connected to the remote server's Singleton object. During the test, they have encountered some very strange behavior. In a test scenario, the client calls to CocreateInstanceex allows them to connect to the Singleton object. In another scene, the same call to COCREATEINSTANCEEX generates multiple object instances and multiple server processes, so that the client cannot connect to the same object instance, thereby actually affecting the application. In these two scenarios, hardware and software are identical.
This problem seems to be related to safety. When the COM Service Control Manager (SCM) that is processed remotely, it assigns an identifier to the process when starting a process on another machine. Unless otherwise specified, the identifier it is to start the user's identity. In other words, the identity assigned to the server process is the same as the identity of the client process that starts it. In this case, if the BOB logs in machine A and connects the Singleton object on the machine B using the CoCreateInstanceEx, and Alice is also in the machine C, which will start two different server processes (at least two different WinStation). ), In fact, make the client unable to connect with the Singleton semantic to the shared object instance.
The reason why the two test scenarios will produce a large phase of the trunks, whose reasons are in a scene (that can work), all testers use a special account set to test with the same person's identity. In another scene, testers use their ordinary user account login. When two or more client processes have the same identity, they can be successfully connected to the server process configured to assume the launch user identifier. However, if the client has a different identifier, the SCM uses multiple server processes (each unique client ID) to assign the identity of different object instances.
Figure 1 User account in DCMCNFG
After finding the problem, it is very simple to solve: Configure the COM server, let it use a specific user account instead of assumed the identity of the user. One way to accomplish this is to run DCOMCNFG (Microsoft's DCOM Configuration Tool) on the server machine and change "Launching User" to "THIS USER" (see Figure 1). If you prefer to make changes (possibly from the installer), add a RunAs value in the COM server entry of the HKEY_CLASSES_ROOT / AppID section of the host registry (see Figure 2). You also need to use LSAStorePrivatedata to store the password of the RunAs account as the LSA key and use LsaAdDaccounts to ensure that the account has the "logon as batch job" permission. (For example, see the DCOMPERM example in the Platform SDK. Special attention to the function named SetrunasPassword and SetaccounTrights.)
