Vérification des threads bloqués

RPC a besoin que ses threads de travail soient disponibles pour fonctionner normalement. Un problème courant est que certains composants du même processus se bloquent tout en conservant l’une des sections critiques globales (par exemple, verrouillage du chargeur ou verrou de tas). Cela entraîne le blocage de nombreux threads, y compris peut-être certains threads de travail RPC.

Si cela se produit, le serveur RPC ne répond pas au monde extérieur. Les appels RPC à celui-ci retournent RPC_S_SERVER_UNAVAILABLE ou RPC_S_SERVER_TOO_BUSY.

Un problème similaire peut se produire si un pilote défectueux empêche les irps de se terminer et d’atteindre le serveur RPC.

Si vous pensez que l’un de ces problèmes peut se produire, utilisez DbgRpc avec le commutateur -t (ou utilisez l’extension !rpcexts.getthreadinfo ). L’ID de processus doit être utilisé comme paramètre. Dans l’exemple suivant, supposons que l’ID de processus est 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 colonne TID fournit l’ID de thread pour chaque thread. La colonne LASTTIME contient l’horodatage de la dernière modification d’état pour chaque thread.

Chaque fois que le serveur reçoit une demande, au moins un thread change d’état et son horodatage est mis à jour. Par conséquent, si une requête RPC est envoyée au serveur et qu’elle échoue, mais qu’aucun des horodatages ne change, cela indique que la demande n’atteint pas réellement l’exécution RPC. Vous devez examiner la cause de ce problème.