Can you identify which processes are using an ncalrpc RPC Endpoint externally? - debugging

Question

When our devs are trying to debug a C++/Winrt ncalrpc RPC server after attaching the newly built and running server process to a VS2017 debugger, they can't breakpoint to new or modified lines of code even if enabling breakpointing to code that isn't exactly the same; it produces an unexpected symbol error message inside the IDE.
I was informed by a team member this was happening due to lingering RPC connections to the RPC Endpoints from other apps and services that use the core service. I don't know a lot about RPC but have been reading up. Checking the core service's source seems to indicate that they're doing everything correctly for stopping the server,
RPC_STATUS rs = 0;
rs = RpcMgmtStopServerListening(NULL);
//...
rs = RpcServerUnregisterIf(RPC_IF_SPEC, nullptr, 0);
//...
rs = RpcEpUnregister(RPC_IF_SPEC, BindingVector, nullptr);
But to be honest it could also be that they should be using rs = RpcServerUnregisterIf(NULL, NULL, 0); instead, I really couldn't say.
Right now we either have to manually track down all the processes that connect to this service and kill/stop them or take the "easy" way out and perform a reboot after installing the new service, allowing us to debug in the correct file locations when attaching the process to VS2017.
My utility idea to get around this was to see if I can generate a list of processes connecting to the RPC Endpoint, nuke them, install the new service, then restart them.
Alternatively this article seems to indicate that avoiding this issue in the first place is possible via something called an Associations, but is somewhat vague on how to do that.
The association itself is reference-counted, and when all references are gone, it stops and closes all connections. Every binding handle and every context handle hold a reference on the association. When all are closed, the association disappears.
Update:
The accepted answer indicates this is not possible with an external process; it is not a way to accomplish this goal with an external process.

Answer 1

RPC has an RpcServerInqCallAttributes function that an RPC server can use during a client call to obtain the client's security context attributes and other information.
You must pass a RPC_CALL_ATTRIBUTES_V2 available only with Windows Vista and higher Windows version (or RPC_CALL_ATTRIBUTES_V3 availble with Windows 8 and higher), so something like this:
// the code depends on the minimal platform you compile for
RPC_CALL_ATTRIBUTES atts = { 0 }; // should map to RPC_CALL_ATTRIBUTES_V2 or RPC_CALL_ATTRIBUTES_V3
atts.Version = RPC_CALL_ATTRIBUTES_VERSION; // should be 2 or 3
atts.Flags = RPC_QUERY_CLIENT_PID;
RpcServerInqCallAttributes(0, &atts);
... pid is in atts.ClientPID ...
This can only be called from the RPC server itself, so you'd have to record all client pids somehow and add some API to the server to be able to list them.