Partilhar via

Verificando se há threads presos

  • Artigo

O RPC precisa de seus threads de trabalho disponíveis para ser executado normalmente. Um problema comum é que algum componente no mesmo processo fará deadlock enquanto mantém uma das seções críticas globais (por exemplo, bloqueio do carregador ou bloqueio de heap). Isso fará com que muitos threads fiquem travados , possivelmente incluindo alguns threads de trabalho RPC.

Se isso ocorrer, o servidor RPC não responderá ao mundo externo. As chamadas RPC para ele retornarão RPC_S_SERVER_UNAVAILABLE ou RPC_S_SERVER_TOO_BUSY.

Um problema semelhante poderá resultar se um driver com falha impedir que IRPs sejam concluídos e cheguem ao servidor RPC.

Se você suspeitar que um desses problemas possa estar ocorrendo, use DbgRpc com a opção -t (ou use a extensão !rpcexts.getthreadinfo ). A ID do processo deve ser usada como um parâmetro. No exemplo a seguir, suponha que a ID do processo seja 0xC4:

D:\wmsg>dbgrpc -t -P c4
Searching for thread info ...
## PID  CELL ID   ST TID      LASTTIME
-----------------------------------
00c4 0000.0004 03 0000011c 000f164f
00c4 0000.0007 03 00000120 008a6290
00c4 0000.0015 03 0000018c 008a6236
00c4 0000.0026 03 00000264 0005c443
00c4 0000.002d 03 00000268 000265bb
00c4 0000.0030 03 0000026c 000f1d32
00c4 0000.0034 03 00000388 007251e9

A coluna TID fornece a ID do thread para cada thread. A coluna LASTTIME contém o carimbo de data/hora da última alteração no estado de cada thread.

Sempre que o servidor receber uma solicitação, pelo menos um thread alterará o estado e seu carimbo de data/hora será atualizado. Portanto, se uma solicitação RPC for feita ao servidor e a solicitação falhar, mas nenhum dos carimbos de data/hora for alterado, isso indicará que a solicitação não está realmente atingindo o tempo de execução do RPC. Você deve investigar a causa disso.