Investigación de un BAD_POOL_HEADER subtipo 0x20 (I)
Ha habido un crimen: una rutina de gestión de memoria, ExFreePoolWithTag, se ha encontrado malherido a un pool y no hay testigos del suceso. Un amigo de la víctima, acompañado de ExFreePoolWithTag, ha declarado: "ya estaba así cuando llegué, yo sólo quería devolverle un préstamo que me hizo y ExFreePoolWithTag me ha avisado; ha sido horrible". La policía no tiene pruebas contra él.
Hace poco me enfrenté en mi sistema Windows XP Service Pack 2 a un error de pantalla azul de tipo BAD_POOL_HEADER (STOP 0x19) con el primer parámetro igual a 0x20. Cada vez que se solicita una asignación o liberación dinámica de memoria del kernel, las rutinas correspondientes comprueban la consistencia de las estructuras de gestión dinámica de memoria (pools). Si observan alguna corrupción seria detienen la máquina, siendo BAD_POOL_HEADER uno de los posibles códigos de error. Esto se debe normalmente a validación insuficiente de punteros: algún módulo ha escrito en una zona de memoria que no debería corresponderle, pero en modo kernel no hay forma de hacer respetar ciertos límites.
Vemos así que la causa del problema no se revela inmediatamente, ya que el daño se observa a posteriori, después de que haya ocurrido, no en el momento en que sucede. Además, la información de la pila de llamadas (call stack) no es concluyente en la mayoría de los casos: el módulo que pidió el bloque de memoria afectado por la corrupción (el que consta en el volcado de pila) no tiene por qué ser el mismo que lo ha corrompido.
El error BAD_POOL_HEADER engloba varios tipos de infracción. El que nos interesa aquí es el que tiene el primer parámetro igual a 0x20 (32 en hexadecimal). La documentación de Microsoft lo describe así:
| Parámetro 1 |
Parámetro 2 |
Parámetro 3 |
Parámetro 4 |
Causa del error |
|
0x20
|
La entrada del pool que debería haberse encontrado
|
La siguiente entrada del pool
|
Reservado
|
El tamaño de la cabecera del bloque de pool se ha corrompido
|
En un próximo artículo expondré el problema concreto que tuve y cómo pude demostrar quién lo provocaba. Sin embargo, cada pantallazo azul es un mundo: las técnicas que mostraré quizá no sean eficaces ante casos similares, pero serán mejores que no hacer nada.
Actualización (7/6/2007): la puesta a punto de la segunda parte se demorará unos días más. Borré los archivos de volcado de memoria antes de decidirme a escribir sobre el proceso de investigación y tampoco guardé el registro de texto del depurador. Ahora estoy intentando reproducir las condiciones del problema para obtener nuevos volcados de memoria, pero no es tan sencillo como pensaba. Lo siento.