Controllo dei thread bloccati

RPC richiede i thread di lavoro disponibili per eseguire normalmente. Un problema comune è che alcuni componenti nello stesso processo verranno deadlock durante la conservazione di una delle sezioni critiche globali (ad esempio, blocco del caricatore o blocco heap). In questo modo molti thread verranno sospesi, molto probabilmente inclusi alcuni thread di lavoro RPC.

In questo caso, il server RPC non risponderà al mondo esterno. Le chiamate RPC a tale oggetto restituiranno RPC_S_SERVER_UNAVAILABLE o RPC_S_SERVER_TOO_BUSY.

Un problema simile può causare se un driver difettoso impedisce ai provider di accesso di completare e raggiungere il server RPC.

Se si sospetta che si verifichi uno di questi problemi, usare DbgRpc con l'opzione -t (o usare l'estensione !rpcexts.getthreadinfo ). L'ID processo deve essere usato come parametro. Nell'esempio seguente si presuppone che l'ID processo sia 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

La colonna TID fornisce l'ID thread per ogni thread. La colonna LASTTIME contiene il timestamp dell'ultima modifica nello stato per ogni thread.

Ogni volta che il server riceve una richiesta, almeno un thread cambierà lo stato e il relativo timestamp verrà aggiornato. Pertanto, se viene effettuata una richiesta RPC al server e la richiesta ha esito negativo, ma nessuno dei timestamp cambia, questo indica che la richiesta non raggiunge effettivamente l'run-time RPC. È consigliabile analizzare la causa di questa operazione.