Compartir a través de

Comprobación de subprocesos bloqueados

  • Artículo

RPC necesita sus subprocesos de trabajo disponibles para realizar normalmente. Un problema común es que algún componente del mismo proceso interbloquee mientras mantiene una de las secciones críticas globales (por ejemplo, bloqueo del cargador o bloqueo del montón). Esto hará que muchos subprocesos se bloquee, muy posiblemente, incluidos algunos subprocesos de trabajo rpc.

Si esto ocurre, el servidor RPC no responderá al mundo exterior. Las llamadas RPC a ella devolverán RPC_S_SERVER_UNAVAILABLE o RPC_S_SERVER_TOO_BUSY.

Un problema similar puede producir si un controlador defectuoso impide que los IRP se completen y lleguen al servidor RPC.

Si sospecha que uno de estos problemas puede producirse, use DbgRpc con el modificador -t (o use la extensión !rpcexts.getthreadinfo ). El identificador de proceso se debe usar como parámetro. En el ejemplo siguiente, supongamos que el identificador de proceso es 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 columna TID proporciona el identificador de subproceso para cada subproceso. La columna LASTTIME contiene la marca de tiempo del último cambio en estado para cada subproceso.

Cada vez que el servidor recibe una solicitud, al menos un subproceso cambiará de estado y se actualizará su marca de tiempo. Por lo tanto, si se realiza una solicitud RPC al servidor y se produce un error en la solicitud, pero ninguna de las marcas de tiempo cambia, esto indica que la solicitud no llega realmente al tiempo de ejecución de RPC. Debe investigar la causa de esto.