Freigeben über

Überprüfen auf hängen gebliebene Threads

  • Artikel

RPC benötigt die verfügbaren Workerthreads, um eine normale Ausführung zu ermöglichen. Ein häufiges Problem besteht darin, dass einige Komponenten im gleichen Prozess einen Deadlock erhalten, während sie einen der globalen kritischen Abschnitte (z. B. Ladeprogrammsperre oder Heapsperre) enthält. Dies führt dazu, dass viele Threads hängen bleiben – sehr wahrscheinlich auch einige RPC-Workerthreads.

In diesem Fall reagiert der RPC-Server nicht an die Außenwelt. RPC-Aufrufe geben RPC_S_SERVER_UNAVAILABLE oder RPC_S_SERVER_TOO_BUSY zurück.

Ein ähnliches Problem kann auftreten, wenn ein fehlerhafter Treiber verhindert, dass IRPs abgeschlossen werden und den RPC-Server erreichen.

Wenn Sie vermuten, dass eines dieser Probleme auftritt, verwenden Sie DbgRpc mit dem Schalter -t (oder verwenden Sie die Erweiterung !rpcexts.getthreadinfo ). Die Prozess-ID sollte als Parameter verwendet werden. Im folgenden Beispiel wird davon ausgegangen, dass die Prozess-ID 0xC4 ist:

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

Die Spalte TID gibt die Thread-ID für jeden Thread an. Die LASTTIME-Spalte enthält den Zeitstempel der letzten Zustandsänderung für jeden Thread.

Wenn der Server eine Anforderung empfängt, ändert sich mindestens ein Thread den Zustand, und sein Zeitstempel wird aktualisiert. Wenn also eine RPC-Anforderung an den Server gestellt wird und die Anforderung fehlschlägt, aber sich keiner der Zeitstempel ändert, bedeutet dies, dass die Anforderung nicht tatsächlich die RPC-Laufzeit erreicht. Sie sollten die Ursache dafür untersuchen.