スタックしたスレッドの確認

RPC が正常に動作するには、ワーカー スレッドが使用可能である必要があります。 よくある問題は、グローバル クリティカル セクションの 1 つ (ローダー ロックやヒープ ロックなど) を保持している間に、同じプロセス内の一部のコンポーネントがデッドロックに陥ることです。 これにより多くのスレッドがハングし、その中に RPC ワーカー スレッドが含まれる可能性が非常に高くなります。

この場合、RPC サーバーは外部に応答しません。 それに対する RPC の呼び出しは、RPC_S_Standard Edition RVER_UNAVAILABLE または RPC_S_Standard Edition RVER_TOO_BUSY を返します。

ドライバーの欠陥により IRP が完了せず、RPC サーバーに到達できない場合にも、同様の問題が発生する可能性があります。

これらの問題のいずれかが発生していると思われる場合は、DbgRpc を -t スイッチ付きで使用します (または、!rpcexts.getthreadinfo 拡張機能を使用してください)。 プロセス ID はパラメーターとして使用します。 次の例では、プロセス ID が 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

TID 列には、各スレッドのスレッド ID が表示されます。 LASTTIME 列には、各スレッドの状態が最後に変更されたときのタイム スタンプが含まれています。

サーバーが要求を受信するたびに、少なくとも 1 つのスレッドが状態を変更し、そのタイムスタンプが更新されます。 したがって、RPC 要求がサーバーに行われ、要求が失敗してもタイム スタンプが変更されない場合は、要求が実際に RPC ランタイムに到達していないことを示します。 この原因を調査する必要があります。