dbgrpc.exe that comes with windbg does not seem to work well under Windows 7. I have followed the instructions, enabling RPC state information as stated in MSDN
I created test out-of-proc COM server and client, run client under debugger, invoke COM server method (step into method before return) and run dbgrpc. I was able to enumerate the RPC endpoints. However, when I try to get thread info like such:
dbgrpc -t -P 1234
Nothing useful was printed - just header without any data row:
PID CELL ID ST PNO IFSTART THRDCELL CALLFLAG CALLID LASTTIME CONN/CLN
I've fount information that other people encountered the same problem on Windows 7 (and OK on Windows XP). So, I suspect that this is the issue of Windows 7 (maybe its security). Similar problem within WinDbg - no useful information running !rpcexts.getcallinfo 0 0 FFFF 1234. Any suggestions?
Forget "dbgrpc" on Vista and later because it's just not working. Vista and later use ALPC ("advanced") instead of old LPC. If you want to analyse ALPC ports and messages, you can kernel-debug the machine and use the command "!alpc". But don't expect much documentation, it's not even mentioned in WinDbg help.
To avoid this kernel mess, I use the "ReservedForOle" pointer in the thread's TEB (offset 0xf80) where COM stores process and thread IDs. The following commands can be used to access them for WinDbg:
In COM-server: where is an incoming COM-call is coming from: Caller's process ID: ? dwo(dwo(@$teb + 0xf80) + 0x108) Caller's thread ID (will be 0 if the caller's thread is in MTA, or -1 if in NA): ? dwo(dwo(@$teb + 0xf80) + 0x34)
In COM-client: where is an outgoing COM-call going to: Target's process ID: ? dwo(dwo(@$teb + 0xf80) + 0x100) Target's thread ID (will be 0 if the target server is a MTA COM-server): ? dwo(dwo(@$teb + 0xf80) + 0x104)
These values are for 32-bit processes. For native 64-bit processes, the offsets would be different (e.g. "ReservedForOle" is on the offset 0x1758 in TEB).