Hi,
I had a post on the temp. msgboard about debugging Remote Procedure Calls (RPC) on Windows.
Since it appears to have died with the temp board, I will post again here. (nb: this has nothing to do with the recent msblaster issue)

I was debugging functions relative to the Open SC Manager on 2K/XP, to see how they were handled internally, and quickly realized the code in advapi was just a stub that called an RPCRT4 function (NdrClientCall2). Now the tricky part is inside rpcrt4... the NdrClientCall2 ends up sending its request and just turns into a "listen mode", waiting for the reply to arrive. When it gets the reply, it copies the result into the user supplied buffer, and returns back into advapi.

Does anyone have ideas/suggestions/docs/tricks/tools that I could use to make my debugging easier? I don't know how to monitor the other side of the rpc calls, i.e: the one processing the request. Any info would be appreciated.

Furthermore, does anyone here have experience in debugging Open SC Manager's internals?

--
dougg

Doug,

Could you tell just between what and what are you waiting for a response from? For example, could you inform what is on the other side of the RPC call?

For e.g.: Are you trying to converse with a Web Server on the other side? A news server? A chat server?

You see, there is software involved at both ends. one that sends the RPC and other that processes the rpc and replies back. Could you provide more information on what softwares are being used at both ends?

have Phun

This is essentially what I am trying to find out when I trace Open SC Manager- related functions..

A concrete example:

a call to EnumServiceStatus follows approximately that route on my XP system:

my_code
_EnumServicesStatusA@32 (ADVAPI32)
-> _REnumServicesStatusA@32 (ADVAPI32)
->->_NdrClientCall2 - (RPCRT4)
->->->[...] and eventually
->->->OSF_CCALL__FastSendReceive (RPCRT4)
->->->->OSF_CCALL__ReceiveReply (RPCRT4)

This is why i'm looking forward to get advice on how to debug rpcrt4, because I would like to know where my request is _really_ handled (i.e: "the other side".

Well after looking around, I can confirm this is a windows interprocess/user<->subsystem communication system..

The Local Procedure Call (LPC), which is yet another undocumented windows element.

I've had the online version of "Undocumented Windows NT" by Dabak, Phadke, Borate for quite some time here (there is an online (free) html version available on a publisher's website.. that I mirrored on my hdd:P), and I only noticed today that it dedicates a whole chapter to the LPC.

I'll do some reading & post more info in here if I find any.

--
Thanks to kayaker for sharing his ideas with me on that subject.

I should have found this earlier I guess, but here is how the communication is done:

When debugging EnumServicesStatus, all the way down in rpcrt4.dll, there is a call to "NMP_SyncSendRecv"

(send-recv because it expects data to return)

which finally does:
[...]
push dword ptr [esi+18h] ; handle to NamedPiPe
call ds:__imp__TransactNamedPipe@28

on the Named Pipe:
\Pipe\svcctl

after googling a little..
i found: "... \SvcCtl named pipe (the Service Control Manager)".. exactly what I'm looking for.

Then I tried to find what created this named pipe.. no luck searching through my whole hdd for "svcctl" (but then, it could be in unicode format in some file...)

I tried the registry, SYSTEM\CurrentControlSet\Services\Npfs\Aliases : there's a string called "ntsvcs" which has to following values "eventlog svcctl".

To make sure I was dealing with the right .sys driver, i checked what the entrypoint of ntfs looked like..

well, In DriverEntry, there is a call to "NpInitializeAliases", which reads the registry and creates the aliases that i just stated above... got it

--
doug

Cool, always fun with yet another part of low-level Windows unraveled. Keep up the digging...

hehe, well

i may have reacted too soon, I'm still not 100% sure that this is the driver handling the sc manager, it just looks like it handles the namedpipes.. If so, I'll just have to dig a little bit more, and I'll be out of town for the next couple days :/

No hurry. But we'll be glad to hear how the story unfolds, whenever it does.

hey, well since the board went down the day I posted this, I will upload the file again:

doug