Processes cannot communicate by COM

Question

I have a program called ProgramA which is a desktop program (GUI) hosting a COM server.
This program is started and kept running.

I have another desktop (WPF) program called ProgramB, written in C#.
The ProgramB instantiates an out-of-process COM proxy communicating with the COM server hosted by the running ProgramA.

All this works fine if both programs are started directly from the same desktop session.

However my real need is to start both programs as another user for example by "runas different user".
Unfortunately this is not working as expected because when ProgramB (runas different user) tries to instantiate the COM server in (already running as different user) ProgramA, it tries to start a new instance of the ProgramA which is disallowed (by check inside ProgramA).

I am pretty sure this has to do with different "COM security contexts" which seems to separate running object tables even if the username and password is identical for both runas different user.

How to fix this problem? (preferably without ProgramB starting ProgramA by instantiating the COM server, for several reasons this is not preferred)

Answer 1

Using "Runas different user" to start a COM Server configured to run as the "Interactive User" will result in a COM error during the process start-up. Obviously, the identity used to start the server differs from the Interactive User identity. For an out-of-process server the error manifests when the server calls CoResumeClassObjects. My test server issues the following and then terminates.

If the desktop application that hosts your out-of-process COM server continues running after this error then it cannot continue successfully as an out-of-process COM server under the "RunAs" identity.

An attempt by a "Runas" client process to instantiate a COM object should fail. My test COM client cannot successfully call CoCreateInstance to instantiate a COM server configured to run with the "Interactive User" identity. The call fails with an "Access Denied" error and I don't see any indication that a second server was started.

Answer 2

Thank you for reaching out. I understand that you are facing an issue where two desktop applications (program A hosting a COM server and program B acting as a COM client) cannot communicate when running under different user contexts using “run as different user".

This behavior is expected due to COM security context isolation. When 2 processes run under different user tokens, even if the credentials are identical, they operate in separate window stations and session object tables which prevents them from sharing the same COM server instance.

Root cause

COM user security boundaries based on user sessions and tokens. When you launch program B under a different user (via runas), the COM Runtime cannot Marshall calls to the already running instance of program A, as it is running in another user session.

As a result, CoCreateInstance will attempt to start a new instance of program A, which program A’s is logic rightfully disallows.

Recommended solution:

Option 1: use COM server activation permissions (DCOMCNFG)

if you want to allow cross user communication:

1.      open component services (DCOMCNFG) -> component services-> computers-> my computer->DCOM config.

2.      Locate your COM server (program A)

3.      right click-> properties-> security tab

4.      Under launch and activation permissions and access permissions, grant the user account of program B the required access.

5.      Ensure authentication level is set appropriately (e.g., “Connect” or “Call”)

Option 2: Configure the COM server as a windows service

if you're designed allows it, register program A as a windows service running under a system or service account. This ensures that the COM object can be accessed across user sessions.

Steps:

1.      move the COM server hosting logic to a windows service.

2.      Configure the service identity (e.g., LocalService, NetworkService, or a custom account)

3.      Set COM Registration to use RunAs= “interactive user" or a specific account.

Option3 : Use named pipes or WCF instead of COM

if modifying architecture is an option, consider replacing out of process COM communication with:

• Named pipes or
• windows communication foundation (WCF) using NetNamedPipeBinding or NetTcpBinding

This avoids COM Security context limitations and allows cross user communication through controlled endpoints .

Referenece:

Https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/choosing-a-transport

If you prefer to keep the COM structure but allow both user to communicate, option one is the quickest fix. However, for maintainability and security option 3 is recommended for future designs.

Please let us know if you require any further assistance we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer".

Answer 3

Thanks to both, combining your comments/answers I think I found the solution.

The DCOM configuration Security tab settings (Launch and Activation, Access and Configuration permissions) does not matter, however the Identity tab changing from The interactive user to The launching user made my day ( I don't know why this particular program was set to The interactive user, most other seems to be set to The launching user, however I assume this is part of the installation of the program).

(Hope I don't meet other problems due to that)