Processes cannot communicate by COM

Magne 166

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)

RLWA32 52,571 Reputation points

2025-11-05T15:31:31.1733333+00:00

Maybe you could share more details about how you constructed the out-of-process COM Server and COM client.

I created a minimal server and client and started them both from a command prompt using the "runas" command so they ran with an identity different from the logged on interactive user. In my quick test the client had no problem connecting to and communicating with the already running server.

For example,

I also tested with the running object table. The client was able to retrieve an interface pointer from the table when both server rand client were started using "runas" as described above.
Magne 166 Reputation points

2025-11-06T08:51:28.5233333+00:00

Thanks.
The real exe server is licenced etc. and should not be exposed here
I will try to setup a simulated server and a simple client for a conceptual repro (in a few days)
RLWA32 52,571 Reputation points

2025-11-06T10:07:27.3+00:00

@Magne, A repro would certainly be helpful. In addition to code, COM registration details and anything specified using DCOM config would also be helpful.
RLWA32 52,571 Reputation points

2025-11-14T09:55:26.4666667+00:00

@Magne, Just checking to see if this issue has been resolved or is still an open item for you.

Answer accepted by question author

RLWA32 52,571

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.

CoResumeError

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.

ComClient

0 comments

Answer accepted by question author

Adiba Khan 2,345 Microsoft External Staff

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".

RLWA32 52,571 Reputation points

2025-11-12T11:23:23.45+00:00

Did you see the example that I illustrated in my comments to the Questioner?
Magne 166 Reputation points

2025-11-14T15:34:03.36+00:00

Thanks Abida KhanI am not sure if your Option 1 is meant to solve my problem (you are mentioning "cross user"), I tried (as far as I can understand your option, but no change.
Please explain the terms "cross user".

Option 2 is not relevant for my case because the Program A is a desktop program with GUI (necessary for other reasons than the COM conncet).

Option 3 is not relevant for my case because Praogram A is a 3rd party program which I cannot modify in any way.
RLWA32 52,571 Reputation points

2025-11-14T15:58:41.7833333+00:00

@Magne, If I understand your question correctly you are starting both the desktop application COM Server and COM client using the same credentials to start both of them with Run As different user (e.g., different identity from logged on interactive user).

In other words, logged on user is account A, COM Server and COM client both started using account B. Is my understanding correct?
Magne 166 Reputation points

2025-11-14T17:49:19.6233333+00:00

Yes, spot on.
RLWA32 52,571 Reputation points

2025-11-14T19:42:59.82+00:00

Yes, spot on.

Well, that is the scenario that I used in the illustration contained in my first comment which showed a successful connection between an already running COM server and COM client.

There are some possibilities that could cause a COM client to not connect to the running server but start a new instance of the server. For example, if the client and server were running at different integrity levels. But you haven't indicated how that might be relevant in your particular circumstance.

Another possibility could be that the COM server registered its class factories as REGCLS_SINGLEUSE. So the running server could be connected to only once. Any subsequent attempt would cause a new instance to be started.

Unfortunately, we just don't have enough information to give you a definitive answer at this point.
Magne 166 Reputation points

2025-11-14T22:03:58.9333333+00:00

I am not sure what you mean by different integrity levels, but I do think they work within separate "COM Security contexts", is that perhaps what you meant?

The "server" desktop app (Program A) has code preventing more than one process instance running simultaneous (i.e. second one i starting up and showing an error message box and terminates when box is acknowledged, but this has nothing do with the instantiation of the COM server proxy by a client (or several clients).
E.g. a test program instantiates 2 such proxies (or actually 2 variable holding the same proxy I think, another instance of this testprogram can do same.
Thus I doubt the REGCLS_SINGLEUSE (is this something I can check in registry? path?)

I think I will check with the issuer of Program A (a huge company) if I break any NDA if shipping the exe in this channel if you would like to do some testing.
It is licensed, but application only issues some "annoyance" if code is not entered (all functionality, including the COM server, is working anyway) so I better check if sharing is ok.
RLWA32 52,571 Reputation points

2025-11-14T22:29:19.02+00:00

Maybe you can get support from the company that authored Program A. And perhaps what you are seeing is related to the licensing scheme used by Program A. Earlier you wrote "All this works fine if both programs are started directly from the same desktop session." How is this different from my example in which the COM server and client ran in the same session and desktop after being started with "runas"?
Magne 166 Reputation points

2025-11-14T22:40:04.4333333+00:00

I can try to get support, but probably they will refuse as my usecase is fairly special. (normally Program A and any client of it will be started directly (not runas)). Why my case differs from yours is weird to me, but it certainly does. Would running the Program A by you be of interest? The setup is quite simple and a testclient to expose the problem is very simple. As an added information it looks like Program B cannot see the COM server in the running object table when runas as described, but certainly can if not runas (I can confirm this in a couple of days)
RLWA32 52,571 Reputation points

2025-11-14T22:55:32.77+00:00

I suggest that you first make inquiry of the Program A author concerning your use case. After all, it's possible they may respond with something more informative than "your use case is not supported."
RLWA32 52,571 Reputation points

2025-11-14T23:01:52.5233333+00:00

Just brainstorming. Another possibility could be that when Program A determines that it has been started under an account that is not the licensed user it does not register its class factories or otherwise perform any COM initialization. If Program A is not running what happens if you start Program B using runas and it calls CoCreateInstance?
Magne 166 Reputation points

2025-11-14T23:16:19.85+00:00

Thanks for trying, but there is no licensing of the user, just the app itself
RLWA32 52,571 Reputation points

2025-11-15T08:53:03.55+00:00

@Magne, Integrity levels are security boundaries that are used throughout Windows. You can read more about them at Mandatory Integrity Control. COM also understands integrity levels.

Lets say that a COM server is running with elevated privileges at a High integrity level. If the system allowed a COM client running at the default Medium integrity level to bind to that server it would be an elevation of privilege security exposure. That's why the Medium integrity client ends up starting a new Medium integrity COM server instead of binding to the already running server. The same principle applies with respect to retrieving an interface pointer from the running object table.
Adiba Khan 2,345 Reputation points Microsoft External Staff

2025-11-17T06:13:50+00:00
Hello @Magne

Thank you for detailed follow up.

Clarification: What “cross-user” means in COM

In the context of COM , “cross-user” refers to situation where

The COM server (program A) is running under User A.

The COM client (program B) is started under user B.

Even if both users belong to the same domain or have the same credentials, Windows still treats them as different security tokens, and therefore in different COM activation contexts.

Because of this separation:

COM does not allow the client (Program B under user B) to connect to the already running COM server instance belonging to User A.

Instead, COM will always try to launch a new instance of Program A under User B.

This is the root cause of behavior, and it is by design.

To make cross-user COM activation work, the following must be configured.

**1.      **DCOM launch & Activation permissions

In component services(DCOMCNFG)

Open component services-> computers-> my computer-> DCOM config.

Locate program A’s COM server entry.

Open Properties -> security lab.

Under launch and activation permissions add user B:

·         Local launch

·         Remote launch

·         Local Activation

·         Remote Activation

**2.      **DCOM Access Permissions

On the same screen, under Access Permissions, add User B:

Local Access

Remote Access

**3.      **Authentication Level

Set program A COM server’s Authentication level to “connect” or “none” depending on its design.

Higher levels such as “Packet” or “Packet Privacy” may block cross-user access.

**4.      **RunAs identity(important)

Check program A’s COM server identity tab:

If it is configured as “the interactive user”, it will always bind to the user session that launched it.

To support cross-user access, set identity to: “The launching user” or a specific user account depending on how the server is registered.

If the COM server is hard code to require “interactive use” (common with 3rd party desktop apps), then Windows session isolation may prevent cross-user COM entirely. In that case, both applications must be launched in the same user session for COM to function

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".

1 additional answer

Magne 166 Reputation points

2025-11-15T09:53:50.12+00:00

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)
Was this answer helpful?
Adiba Khan 2,345 Reputation points Microsoft External Staff

2025-11-19T04:39:25.99+00:00

Thank you for your response.

I truly appreciate that you’ve taken the time to understand the issue thoroughly. It means a lot.

I kindly ask if you feel the answer has addressed your concern please consider accepting the answer it as the confirmed information. Doing so helps the system recognize that the topic has been confirmed, and it provides a valuable reference for other users who may encounter similar questions in the future. It also contributes to building a stronger community and helps increase your reputation score on the platform.

Thank you again for your engagement and support!

Best regards,
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Processes cannot communicate by COM

1 additional answer

Your answer