Geting the ProcessID of the client that makes COM call running as dllSurrogate?

amrut anegundi 1

I am kind of new to COM and had a query. We have registered a COM DLL as DLLSurrogate to run under default dllhost.exe.
We have an app/3rd party app that is consuming this COM, and when we try to get the current process id it is returning the process id of dllhost.exe and not the app.
Is there a way to get the process id of the client that made the COM call (app)?

Petrus 【KIM】 456 Reputation points

2021-04-16T07:20:21.44+00:00

NO WAY! DLL is not executable module. So it must instance(initialize) in host executable programs.
See. Task manager.

2 answers

Song Zhu - MSFT 906 Reputation points

2021-04-16T07:18:15.97+00:00

Refer to: Determine the Process ID of the Client Process communicating with a COM RPC Server
I think you cannot get the identifier of the process.
Please sign in to rate this answer.

1 person found this answer helpful.
amrut anegundi 1 Reputation point

2021-04-17T10:39:33.337+00:00

Is there a way to identify the process since I know that it is a local server and I need a way to get processid to read the exe cert info. Also want to understand if custom surrogate can help here?
Sign in to comment
RLWA32 40,656 Reputation points

2021-04-17T17:21:02.537+00:00

An out-of-process COM server handling an incoming call from a COM client can use the RpcServerInqCallAttributes function and request RPC_QUERY_CLIENT_PID in the RPC_CALL_ATTRIBUTES_V2 struct that is passed to the function.
Please sign in to rate this answer.

1 person found this answer helpful.
amrut anegundi 1 Reputation point

2021-04-19T03:57:12.977+00:00

@RLWA32
I tried out the below code but getting the status as (RPC_S_NO_CALL_ACTIVE)1725 but I was expecting ERROR_MORE_DATA. I even tried assigning to a temp buffer and still got the same error. And also I see RPC_CALL_ATTRIBUTES_V2 disabled as my code is legacy.

RPC_CALL_ATTRIBUTES CallAttributes; // this maps to RPC_CALL_ATTRIBUTES_V1 memset(&CallAttributes, 0, sizeof(CallAttributes)); CallAttributes.Version = RPC_CALL_ATTRIBUTES_VERSION; // maps to 1 CallAttributes.Flags = RPC_QUERY_CLIENT_PRINCIPAL_NAME;//.... RPC_STATUS Status = RpcServerInqCallAttributes(0, &CallAttributes);

The above code is called in the context of dllhost.exe...
Is there something I am missing?

RLWA32 40,656 Reputation points

2021-04-19T15:29:16.623+00:00

The RpcServerInqCallAttributes function should be called while the COM server is handling an incoming call. The error return of RPC_S_NO_CALL_ACTIVE seems to indicate that the function is being called at some other point in processing.

RLWA32 40,656 Reputation points

2021-04-19T16:28:09.93+00:00

Following is the sample code that I used in my test -

RPC_CALL_ATTRIBUTES_V2 rpcAttributes{}; rpcAttributes.Version = 2; rpcAttributes.Flags = RPC_QUERY_CLIENT_PID; RPC_STATUS rpcRet = RpcServerInqCallAttributes(NULL, &rpcAttributes);

amrut anegundi 1 Reputation point

2021-04-19T16:44:15.427+00:00

@RLWA32
I am making the call in the context of dllhost.exe (if I do getprocessid it is returning processid of dllhost.exe) so I believe it is getting called while the COM server is handling an incoming call.
Correct me if I am wrong here?

Since the code is legacy I see that RPC_CALL_ATTRIBUTES_V2 is not defined maybe due to NTDDI_VERSION<NTDDI_VISTA.

RLWA32 40,656 Reputation points

2021-04-19T17:05:52.587+00:00

@amrut anegundi Well, according to the MS documentation the minimum supported client for RPC_CALL_ATTRIBUTES_V2 is Vista. So it is likely that your NTDDI_VERSION setting is a problem.

When I tested I had a COM client invoke an interface method on a COM object hosted by an out-of-process COM server. The method invoked on the COM server called RpcServerInqCallAttributes so it was certain that an incoming call was active.

amrut anegundi 1 Reputation point

2021-04-19T17:13:49.14+00:00

@RLWA32
Thanks for the reply. Need one last confirmation, the above API should work for dllhost.exe as well right or is it mandatory for the surrogate to be custom surrogate?

RLWA32 40,656 Reputation points

2021-04-19T18:00:32.283+00:00

@amrut anegundi Well, it should be easy enough to test when using the standard surrogate.

In the absence of coding errors I expect that RpcServerInqCallAttributes would complete successfully regardless of whether the COM server process was a custom surrogate, the standard surrogate (dllhost.exe) or a typical out-of-process-server (.exe).

amrut anegundi 1 Reputation point

2021-04-19T18:19:15.327+00:00

@RLWA32
Just to give you some context this is what we are doing,
We have a 64bit COM DLL registered and we want a 32bit app/client be able to consume the COM DLL.
We have registered the COM DLL as a DLLSurrogate, to run under the default surrogate process (dllhost.exe).

Registry changes to make the COM DLL as DLLSurrogate
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\AppID{GUID of 64bit comdll}]
"DllSurrogate"=""
[HKEY_CLASSES_ROOT\CLSID{GUID of 64bit comdll}]
"AppID"="{GUID of 64bit comdll}"
Do you see any issue with this?

I am able to see that the COM API call is resulting in getting served from dllhost server but somehow the above API is not working.
Please let me know if I am doing something wrong here

RLWA32 40,656 Reputation points

2021-04-19T18:33:18.833+00:00

@amrut anegundi Based on your earlier comments passing the V1 struct to the function due to your NTDDI_VERSION setting seems to me to be a coding error if you are attempting to retrieve the client pid.

amrut anegundi 1 Reputation point

2021-04-19T19:14:35.833+00:00

@RLWA32
I understand that the above code does not give me the client pid but I was more into testing out if RpcServerInqCallAttributes works for me or not and I see that it still returns (RPC_S_NO_CALL_ACTIVE)1725.
But this is called from DLLHost which means it is an out-of-proc server making the call so ideally the above API should not return 1725 as status code
My question is if the COM API is called in the context of DLLHost.exe then it should be a out-of-proc call and the above API must be successfull.
Not sure why it returns 1725 and also do you see any problem with the registry changes done above? Can a COM call happen via dllhost.exe and still not be a RPC call?
Copying the tested code below

amrut anegundi 1 Reputation point

2021-04-19T19:19:33.003+00:00

Code reference that I tested out

RPC_CALL_ATTRIBUTES rpcAttributes{}; rpcAttributes.Version = RPC_CALL_ATTRIBUTES_VERSION; rpcAttributes.Flags = RPC_QUERY_CLIENT_PRINCIPAL_NAME; unsigned char clientprincipalname[1000]; rpcAttributes.ClientPrincipalNameBufferLength = 1000; rpcAttributes.ClientPrincipalName = &clientprincipalname[0]; RPC_STATUS rpcRet = RpcServerInqCallAttributes(NULL, &rpcAttributes);

RLWA32 40,656 Reputation points

2021-04-19T19:36:00.87+00:00

@amrut anegundi When does your COM server call RpcServerInqCallAttributes?

amrut anegundi 1 Reputation point

2021-04-20T02:56:37.363+00:00

@RLWA32
Inside one of the COM function call of the COM DLL.

RLWA32 40,656 Reputation points

2021-04-20T14:09:51.713+00:00

@amrut anegundi Are you able to successfully call RpcServerInqCallAttributes within 1) a standalone out-of-process COM Server (.exe) or 2) a COM surrogate process whose bitness matches that of the COM client?
Sign in to comment