Traduccion: The Case of the System Process CPU Spikes

Gracias a Ramiro Encinas tenemos traducido este interesante articulo de markrussinovich

Como seguramente has podido suponer por las entradas anteriores en mi blog y en otros artículos, me gusta saber exactamente que hace mi sistema. Quiero saber si un proceso consume demasiada CPU, provocando agobios en memoria, o demasiado trabajo en disco. A parte de mantener mis ordenadores funcionando correctamente, vigilarlos a veces me ayuda a encontrar problemas de rendimiento y fiabilidad en el código de terceros para Windows.

Lo primero que hago es configurar Process Explorer para que se ejecute automáticamente cuando inicio una sesión de Windows. Siempre que configuro un ordenador nuevo, añado un acceso directo a Process Explorer en la carpeta de Inicio de mi perfil incluyendo el parámetro /minimize. De esta forma, Process Explorer se ejecuta oculto con un icono en la barra de notificación donde muestra una pequeña vista histórica del nivel de actividad de la CPU. Como quiero tener información detallada sobre los procesos del sistema a parte de los míos, también especifico el parámetro /e en Vista, y con esto Windows presenta una ventana del UAC que me permite dar a Process Explorer permisos administrativos.

Como siempre tengo un ojo puesto en los picos de CPU del icono de la barra de notificación, que muestra en verde el consumo de CPU del modo usuario (aplicaciones) y en rojo del modo kernel (sistema operativo y drivers), en los último meses he identificado varios problemas. En esta entrada veremos como identificar un problema con un driver de terceros y como llegar a un fix del fabricante, utilizando Process Explorer y Kernrate.

Hace unos meses atrás empezé a utilizar un portátil, y notaba a veces lentitud en el sistema. El icono de Process Explorer confirmaba mi percepción visualizando un mini-gráfico de actividad roja en la CPU. Cuando ubiqué el ratón en el icono, éste abrió una ventana indicando el nombre del proceso que estaba consumiendo más CPU, y en este caso mostraba el proceso de Sistema (System) como responsable:
Las primeras veces que ví el problema, al poco se resolvía sólo y no me daba tiempo a investigarlo. En cualquier caso pude ver, mediante la ventana de Información del Sistema de Process Explorer, que los picos de CPU eran bastante significativos:

El proceso de Sistema es especial porque no tiene un archivo ejecutable como los otros procesos. Sólo funciona para hilos del sistema operativo como el administrador de memoria, el administrador de caché, y otros subsistemas, así como para hilos de los drivers. Estos hilos se ejecutan completamente en modo kernel, y por eso el consumo de CPU por parte del proceso de Sistema aparece en rojo en los gráficos de Process Explorer.

Sospeché que un driver de un tercero era la causa del problema, por eso el primer paso en mi investigación fué localizar el hilo que más CPU consumía para llegar al culpable. Empezé a buscar los picos de CPU y cuando ví uno hice doble click en el proceso del Sistema y fuí a la pestaña "Threads" para ver los hilos. Allí ví el pico de CPU:

El prefijo “ntkrnlpa.exe” en cada dirección de inicio de un hilo lo identifica como un hilo del sistema operativo, y éstos eran los que más consumo de CPU tenían (Ntkrnlpa.exe es la versión cargada de kernel en sistemas cliente de 32-bit que no se ejecuta en memoria protegida o en sistemas servidores que necesitan direccionar más de 4GB de memoria). Debido a que antes configuré Process Explorer para recuperar los símbolos de los ejecutables del sistema operativo del servidor público de símbolos de Microsoft, la lista de hilos también mostraba los nombres de los hilos de las funciones de inicio. Los hilos más activos comienzan con la función ExpWorkerThread, que quiere decir que son hilos que trabajan para los drivers y para el sistema. En lugar de crear hilos dedicados que consumen recursos de memoria, los drivers y el sistema pueden lanzar trabajos al contenedor compartido worker threads del sistema operativo.

Por desgracia, sabiendo que los worker threads son los responsables del gran consumo de CPU, no pude identificar la raíz de la causa. Necesitaba saber cuáles son las funciones llamadas por los worker threads, porque esas funciones pueden estar dentro de un driver o de un componente del sistema operativo en las cuales están corriendo los hilos. Una forma de ver lo que ha ejecutado el hilo es mirar la pila del hilo con Process Explorer. La pila es una región de memoria que guarda las llamadas a las funciones y Process Explorer te muestra la pila del hilo cuando seleccionas un hilo y pulsas en el botón "Stack" o haces doble click en un hilo. Sin embargo, en Vista se produce este error cuando intentas mirar la pila de los hilos en el proceso de Sistema:

El proceso de Sistema es un tipo especial de proceso llamado "proceso protegido" que no permite ningún tipo de acceso a sus hilos o memoria. Los procesos protegidos existen para dar servicio a la Administración de Derechos Digitales (DRM), y con esto, los proveedores de contenido de alta definición pueden guardar claves de cifrado para sus contenidos reduciendo el riesgo de que un usuario con privilegios administrativos pueda utilizar herramientas anti-DRM para llegar al proceso y leer las claves.

Con este intento fallido, tenía que encontrar otra forma de ver lo que estaban haciendo los worker threads. Para ello utilicé KernRate, una herramienta de línea de comandos de descarga gratuita de Microsoft. KernRate puede capturar los procesos en modo usuario y los hilos en modo kernel. KernRate utiliza un recolector que ya utilizó la primera versión de Windows NT, que registra las direcciones únicas que la CPU ejecuta en un momento dado. Cuando paras la captura, KernRate recupera la información del kernel, mapea las direcciones de los drivers cargados, y puede incluso utilizar el motor de símbolos para mostrar los nombres de las funciones.

No son necesarios los símbolos si estamos identificando a un driver, por eso ejecuté KernRate sin ningún parámetro. A pesar del hecho de que no existe una versión oficial de KernRate para Vista, la versión para Windows XP, Kernrate_i386_XP.exe funciona en Vista 32-bit (también puedes utilizar la herramienta xperf recientemente liberada para realizar operaciones similares - xperf requiere Vista o Server 2008 y también funciona en versiones de 64-bit). Ejecuté la captura cuando la CPU estaba dando picos de consumo y entonces con Ctrl+C salieron los resultados en la ventana de la consola:
En primer lugar los picos estaban en el kernel, y en segundo lugar estaba un driver que no conocía: b57nd60x. La mayoría de los archivos de los drivers están en %systemroot%\system32\drivers, y podría abrir esa carpeta para ver las propiedades del archivo, pero tenía abierto Process Explorer y era más rápido comprobar el fabricante del driver y la versión desde la vista de los DLL del proceso de Sistema. La vista de los DLL mostraba las DLLs y los archivos mapeados dentro del espacio de direcciones de los procesos en modo usuario, y para el proceso de Sistema mostraba los módulos del kernel, incluyendo los drivers cargados en el sistema. La vista de las DLL revelaba que el driver era de la tarjeta de red del portátil, fabricado por Broadcom y con versión 10.10:

Ahora que descubrí que el driver de Broadcom era el causante del gran consumo de CPU, el siguiente paso fue ver si había alguna versión nueva disponible. Fuí a la página de descarga de Dell para mi sistema, pero no encontré nada. Sospechando que lo que descubrí tendría que haber ocurrido ya antes, decidí notificarlo a Broadcom. Utilicé los contactos del equipo de sistemas hardware aquí en Microsoft para encontrar el representante del driver de Broadcom y escribirle un correo electrónico detallando la descripción de los síntomas y mi investigación. Él reenvió el email al desarrollador del driver, quien no conocía la causa y me dijo que en unos días me enviaría una versión depurada del driver con símbolos para que KernRate capturara las funciones del driver que provocaban los picos de CPU. El problema ocurrió de nuevo unos días más tarde y le envié de vuelta los resultados de KernRate con la información de las funciones.

El desarrollador me explicó que los resultados revelaban que el driver no interactuaba de forma eficiente con el bus PCIe cuando procesaba consultas espefícicas y el problema parecía provocarse por mi recargada configuración de hardware. Me dió un driver nuevo para probar y después de pocas semanas monitorizando mi portátil confirmé que el problema estaba resuelto. El driver actualizado todavía no está colocado en el sitio de soporte de Dell, pero espero que lo publiquen dentro de poco. Otro caso cerrado, esta vez con Process Explorer, KernRate, y un desarrollador de drivers de Broadcom.