1

Topic: Trace RPC of calls (where you Chris ((()

I welcome. A prelude. If it is short, there is certain server a software. To this software integrators can write any integrations using COM API. By operation of one of such decisions from integrators the server software after some time, days-two, tightly hangs up. The analysis  yet does not bring clearness. In  it is visible the order of 600-700 worker threads, in their normal operation mode nearby 100. The Most part it rpc type calls: 00000001 ` c01ae068 00007ff9 ` bbb1ddb9 ntdll! NtWaitForSingleObject+0xa 00000001 ` c01ae070 00007ff9 ` bbb1b784 ntdll! RtlpWaitOnCriticalSection+0xe1 00000001 ` c01ae140 00007ff9 ` ba9a796a ntdll!RtlpEnterCriticalSectionContended+0xa4 (Inline Function)-------- `-------- combase! COleStaticMutexSem:: Request+0x1a [d:\blue\com\combase\common\olesem.cxx 169] 00000001 ` c01ae180 00007ff9 ` ba9ab0f0 combase! CStdMarshal:: Disconnect (unsigned long dwType = 1) +0xba [d:\blue\com\combase\dcomrem\marshal.cxx 3727] 00000001 ` c01ae1e0 00007ff9 ` ba9abca7 combase! CStdIdentity: :DecStrongCnt (int fKeepAlive = 0n0) +0x93 [d:\blue\com\combase\dcomrem\stdid.cxx 1064] (Inline Function)-------- `-------- combase!CStdMarshal::DecStrongAndNotifyAct+0x3d [d:\blue\com\combase\dcomrem\marshal.cxx 6472] 00000001 ` c01ae220 00007ff9 ` ba9ac37f combase! CStdMarshal:: DecSrvIPIDCnt (struct tagIPIDEntry * pEntry = 0x00000001 ` 66645330, unsigned long cRefs = <Value unavailable error>, unsigned long cPrivateRefs = 0, struct tagSECURITYBINDING * pName = 0x00000000 ` 00000000, unsigned long mshlflags = 0) +0x8f [d:\blue\com\combase\dcomrem\marshal.cxx 6227] 00000001 ` c01ae250 00007ff9 ` b91620f3 combase! CRemoteUnknown:: RemReleaseWorker (unsigned short cInterfaceRefs = 1, struct tagREMINTERFACEREF * InterfaceRefs = 0x00000000 ` 0a06fea8, int fTopLevel = 0n1) +0x213 [d:\blue\com\combase\dcomrem\remoteu.cxx 1133] 00000001 ` c01ae320 00007ff9 ` b9273693 rpcrt4! Invoke+0x73 00000001 ` c01ae380 00007ff9 ` b916a6d0 rpcrt4! Ndr64StubWorker+0xfc9 00000001 ` c01aea80 00007ff9 ` bab197e3 rpcrt4! NdrStubCall3+0x10d 00000001 ` c01aeda0 00007ff9 ` bab1a7bd combase! CStdStubBuffer_Invoke (struct IRpcStubBuffer * This = 0x00000000 ` 00375bc0, struct tagRPCOLEMESSAGE * prpcmsg = 0x00000000 ` a6355e58, struct IRpcChannelBuffer * pRpcChannelBuffer = 0x00000000 ` 00382d40) +0x6b [d:\blue\com\combase\ndr\ndrole\stub.cxx 1586] 00000001 ` c01aede0 00007ff9 ` ba9a3c0a combase! SyncStubInvoke (struct tagRPCOLEMESSAGE * pMsg = 0x00000000 ` a6355e58, struct _GUID * riid = 0x00000000 ` 00385964 {00000134-0000-0000-c000-000000000046}, class CIDObject * pID = 0x00000000 ` 00000000, void * pVtableAddress = 0x00007ff9 ` baa30228, struct IRpcChannelBuffer * pChnl = 0x00000000 ` 00382d40, struct IRpcStubBuffer * pStub = 0x00000000 ` 00375bc0, void * pInterface = 0x00000000 ` 0037cb90, unsigned long * pdwFault = 0x00000001 ` c01af1d0) +0x21d [d:\blue\com\combase\dcomrem\channelb.cxx 1664] (Inline Function)-------- `-------- combase! StubInvoke+0xc0 [d:\blue\com\combase\dcomrem\channelb.cxx 1957] 00000001 ` c01aef80 00007ff9 ` bab1a51f combase! CCtxComChnl:: : ContextInvoke (struct tagRPCOLEMESSAGE * pMessage = 0x00000000 ` a6355e58, struct IRpcStubBuffer * pStub = 0x00000000 ` 00375bc0, struct tagIPIDEntry * pIPIDEntry = 0x00000000 ` 003832a0, unsigned long * pdwFault = 0x00000001 ` c01af1d0) +0x27a [d:\blue\com\combase\dcomrem\ctxchnl.cxx 1377] (Inline Function)-------- `-------- combase! DefaultInvokeInApartment+0x51 [d:\blue\com\combase\dcomrem\callctrl.cxx 2716] 00000001 ` c01af190 00007ff9 ` bab19fb0 combase! AppInvoke (class CMessageCall * pCall = 0x00000000 ` a6355db0, class CRpcChannelBuffer * pChannel = 0x00000000 ` 00382d40, struct IRpcStubBuffer * pStub = 0x00000000 ` 00375bc0, void * pv = <Value unavailable error>, void * pStubBuffer = 0x00000000 ` 0a06fe98, struct tagIPIDEntry * pIPIDEntry = 0x00000000 ` 003832a0, union WireLocalThis * pLocalb = 0x00000000 ` 0a06fe88) +0x1af [d:\blue\com\combase\dcomrem\channelb.cxx 1481] 00000001 ` c01af280 00007ff9 ` bab1ab35 combase! ComInvokeWithLockAndIPID (class CMessageCall * pCall = 0x00000000 ` a6355db0, struct tagIPIDEntry * pIPIDEntry = 0x00000000 ` 003832a0) +0x676 [d:\blue\com\combase\dcomrem\channelb.cxx 2314] 00000001 ` c01af4c0 00007ff9 ` b9162467 combase! ThreadInvoke (struct _RPC_MESSAGE * pMessage = 0x00000000 ` d5549970) +0x48a [d:\blue\com\combase\dcomrem\channelb.cxx 5488] 00000001 ` c01af590 00007ff9 ` b91622c0 rpcrt4! DispatchToStubInCNoAvrf+0x33 00000001 ` c01af5e0 00007ff9 ` b916aa88 rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x190 00000001 ` c01af6e0 00007ff9 ` b9162d26 rpcrt4! LRPC_SCALL:: DispatchRequest+0x4c9 00000001 ` c01af7f0 00007ff9 ` b9162b78 rpcrt4! LRPC_SCALL:: HandleRequest+0x291 00000001 ` c01af8a0 00007ff9 ` b916195d rpcrt4!LRPC_SASSOCIATION::HandleRequest+0x238 00000001 ` c01af930 00007ff9 ` b916175e rpcrt4! LRPC_ADDRESS:: ProcessIO+0x444 00000001 ` c01afa70 00007ff9 ` bbb1af00 rpcrt4! LrpcIoComplete+0x144 00000001 ` c01afb10 00007ff9 ` bbb19238 ntdll! TppAlpcpExecuteCallback+0x210 00000001 ` c01afb80 00007ff9 ` bb2513d2 ntdll! TppWorkerThread+0x888 00000001 ` c01aff60 00007ff9 ` bbaf54e4 kernel32! BaseThreadInitThunk+0x22 00000001 ` c01aff90 00000000 ` 00000000 ntdll! RtlUserThreadStart+0x34 and type such 00000000 ` 211ef538 00007ff9 ` bbb1ddb9 ntdll! NtWaitForSingleObject+0xa 00000000 ` 211ef540 00007ff9 ` bbb1b784 ntdll! RtlpWaitOnCriticalSection+0xe1 00000000 ` 211ef610 00007ff9 ` ba9a40bd ntdll!RtlpEnterCriticalSectionContended+0xa4 (Inline Function)-------- `-------- combase! COleStaticMutexSem:: Request+0x19 [d:\blue\com\combase\common\olesem.cxx 169] 00000000 ` 211ef650 00007ff9 ` b9169ea4 combase! ORPCInterfaceSecCallback (void * Interface = 0x00000000 ` 211ef7b0, void * Context = 0x00000000 ` 4e863bc0) +0x121 [d:\blue\com\combase\dcomrem\security.cxx 2071] 00000000 ` 211ef750 00007ff9 ` b9169f62 rpcrt4!RPC_INTERFACE::DoSecurityCallbackHelper+0xa4 00000000 ` 211ef7f0 00007ff9 ` b9162b78 rpcrt4! LRPC_SCALL:: HandleRequest+0x555 00000000 ` 211ef8a0 00007ff9 ` b916195d rpcrt4!LRPC_SASSOCIATION::HandleRequest+0x238 00000000 ` 211ef930 00007ff9 ` b916175e rpcrt4! LRPC_ADDRESS:: : ProcessIO+0x444 00000000 ` 211efa70 00007ff9 ` bbb1af00 rpcrt4! LrpcIoComplete+0x144 00000000 ` 211efb10 00007ff9 ` bbb19238 ntdll! TppAlpcpExecuteCallback+0x210 00000000 ` 211efb80 00007ff9 ` bb2513d2 ntdll! TppWorkerThread+0x888 00000000 ` 211eff60 00007ff9 ` bbaf54e4 kernel32! BaseThreadInitThunk+0x22 00000000 ` 211eff90 00000000 ` 00000000 ntdll! RtlUserThreadStart+0x34 and similar to these Looked , found only mutual locks between RPC calls, and without stopping in our code. Google on debugging RPC produces a little that intelligible. From this that there was it: https://docs.microsoft.com/en-us/window … -debugging  in a sandbox with that that there is offered, I will try to put into practice when the server hangs up repeatedly. On this subject found Chris Kasperski's old article/note  Myshchh: https://nezumi.cyberpunk.us/articles/windbg-rpc the mechanism explicitly enough is considered how to trace win api calls and there is a mention that approximately as it is possible to make trace and for rpc calls using the extension for windbg rpcexts.dll, and further stop short a breakaway. Well and in article it is a lot of at first a lot of superfluous water, it is possible to press time in three precisely. Whether it is possible somehow  all rpc process calls, I did not understand analogies on which Chris specifies? MS suggests to understand with the last state of system, but it would be possible useful to have broad gulls with a time reference. Google did not find in anything relevant on this subject. This subject  rpc can and its debuggings somewhere is in more details uncovered? That read up thanks.