Error en SP3: "se ha encontrado un valor de..."

Más
8 años 7 meses antes - 8 años 7 meses antes #15027 por Califa101

Asterixco escribió: Cuando veas que Poolmon funciona correctamente mostrando unas estadísticas al ejecutarlo, con líneas de información del sistema en la parte superior y una tabla con letras en la primera columna y números en las siguientes, seguimos.


Ya lo he hecho. He modificado el registro, como me indicabas, y he descargado la herramieta Windows XP SP2 Support Tools. Y, efectivamente, cuando ejecuto el comando Poolmon me sale una pantalla de fondo azul con una serie de indicadores y columnas, algunas de los cuales van cambiando. Si lo necesitas, puedo subir una imagen de la pantalla.
Última Edición: 8 años 7 meses antes por Califa101.

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
8 años 7 meses antes #15028 por Asterixco
Bien, es suficiente.

Los componentes que se ejecutan en modo núcleo identifican cada tipo de asignación de memoria con una etiqueta. Por ejemplo, 8042 corresponde al controlador de ratón y teclado PS/2, Proc y la mayoría de Ps?? (donde ? representa una letra o número) suelen relacionarse con estructuras relativas a procesos, Thre son objetos de thread (hilo o subproceso), los Cc?? son estructuras del gestor de caché, Io?? representan operaciones de entrada y salida, Mm?? se asocia al gestor de memoria, etc.

Hay un detalle de "culturilla" que no he comentado antes: existen dos razones fundamentales por las que se definen las dos áreas separadas paginada (paged pool) y no paginada (nonpaged pool), en lugar de una sola. La primera: los sistemas basados en memoria virtual se ayudan de los fallos de página del procesador para simular un mayor espacio de memoria intercambiando porciones de información en memoria física y en disco. Algunos componentes del sistema y varias estructuras de datos esenciales deben residir permanentemente en memoria física, incluyendo el propio gestor de fallos de página (si no, ¿cómo se recuperaría a sí mismo una vez volcado al disco?). Además, hay momentos especiales durante la ejecución de Windows en los que no está permitido satisfacer fallos de página (la infracción de esta regla es la causa de los pantallazos azules más habituales). Para eso está el área de memoria no paginada. Segunda razón: mantener todas las estructuras de datos en esta área sería un derroche, sobre todo en equipos con poca memoria física. Si una estructura de datos no es "esencial" debería poder volcarse al disco para dejar espacio de memoria a las aplicaciones, que son las que dan utilidad real a un sistema operativo, y recuperarse cuando haga falta. Esta es la función del área paginada.

La cabecera de la ejecución de Poolmon muestra varias estadísticas sobre el uso de memoria. Al final de la segunda línea, al menos uno de los valores que acompaña a la palabra Pool debería ser el que aumenta más de la cuenta desencadenando el error 1450. Por otra parte, la descripción de las columnas de la tabla es la siguiente:
  • Tag: etiqueta.
  • Type: Paged si pertenece a memoria paginada, Nonp si pertenece a memoria no paginada.
  • Allocs: total de solicitudes de memoria que han sido satisfechas (asignaciones).
  • Frees: total de liberaciones de memoria.
  • Diff: diferencia entre Allocs y Frees, es decir, número de bloques de memoria que pueden estar en uso actualmente.
  • Bytes: tamaño total de las asignaciones de memoria actuales.
  • Per Alloc: división de Bytes entre Diff como valor medio del tamaño de cada asignación de memoria.
Los números entre paréntesis señalan la variación del valor al que acompañan con respecto a la actualización anterior de la pantalla. Los cambios aparecen resaltados.

Pulsa la tecla D para ordenar la información por la columna Diff de manera descendente. Si el Diff de la primera fila fuese notablemente superior al resto, tendríamos ya de inicio un posible sospechoso. También es factible ordenar por bytes con la tecla B, pero podría suceder que un componente haya pedido pocos bloques grandes y otro componente haya solicitado muchos de pequeño tamaño, de forma que el total de bytes sea similar. En tal caso, Diff y Per Alloc destacarían la diferencia entre ambos. Ve observando la evolución del uso de memoria en la pantalla a distintos intervalos y, si es necesario, intenta de nuevo la instalación del service pack para obligar de algún modo a que se manifieste el problema.

Si la hipótesis de la fuga de memoria es correcta, el uso de memoria del área paginada, o bien de la no paginada, y el Diff o los Bytes de una etiqueta en concreto habrían de crecer desmesuradamente en relativamente poco tiempo y, además, no recuperando posteriormente sus niveles anteriores (bajando mucho más despacio o nada en absoluto).

Una vez identificada la etiqueta bajo la que se camufla la posible fuga de memoria, hay que hallar el controlador o subsistema al que pertenece. Los últimos WDK (Windows Driver Kits) y el paquete de herramientas de depuración (Debugging Tools for Windows) incorporan un archivo de texto denominado Pooltag.txt con etiquetas "bien conocidas" de subsistemas del núcleo, controladores propios de Windows y algunos controladores de terceros. Déjanos por aquí las primeras líneas de la pantalla de Poolmon.

El artículo 298102 de la Knowledge Base de Microsoft sugiere un método para hallar el origen de una etiqueta que no consta en el archivo Pooltag.txt, pero no sirve más que en las versiones de 32 bits porque el formato de instrucción y el paso de parámetros es diferente en otras arquitecturas. Consiste en recorrer los archivos *.sys del disco duro, especialmente la carpeta %Systemroot%\System32\Drivers, buscando la etiqueta como una cadena de texto. Para intentar reducir los falsos positivos se coloca una 'h' minúscula delante de la etiqueta, puesto que su código ASCII, es decir, 104 en decimal o 0x68 en hexadecimal, es el código de operación de la instrucción "PUSH <valor_inmediato>" en la arquitectura x86; en este caso el valor inmediato de la instrucción, que se pasa como parámetro a la función de asignación de memoria, es la propia etiqueta representada como un número de 32 bits.

Más información:
KB177415: Cómo usar el monitor de grupos de memoria (Poolmon.exe) para solucionar problemas de pérdidas de memoria en el modo de núcleo
KB298102: Cómo encontrar etiquetas de grupo que utilizan controladores de terceros

Ramón Sola | Málaga (España)

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
8 años 7 meses antes #15029 por Califa101
Hola.

Asterixco escribió: Pulsa la tecla D para ordenar la información por la columna Diff de manera descendente. Si el Diff de la primera fila fuese notablemente superior al resto, tendríamos ya de inicio un posible sospechoso. También es factible ordenar por bytes con la tecla B, pero podría suceder que un componente haya pedido pocos bloques grandes y otro componente haya solicitado muchos de pequeño tamaño, de forma que el total de bytes sea similar. En tal caso, Diff y Per Alloc destacarían la diferencia entre ambos. Ve observando la evolución del uso de memoria en la pantalla a distintos intervalos y, si es necesario, intenta de nuevo la instalación del service pack para obligar de algún modo a que se manifieste el problema.[/url]


Después de ordenar la columna DIFF, la fila correspondiente al tag KEY marca 37356, y la segunda correspondiente al tag :NTI marca 6805.

Asterixco escribió: Una vez identificada la etiqueta bajo la que se camufla la posible fuga de memoria, hay que hallar el controlador o subsistema al que pertenece. Los últimos WDK (Windows Driver Kits) y el paquete de herramientas de depuración (Debugging Tools for Windows) incorporan un archivo de texto denominado Pooltag.txt con etiquetas "bien conocidas" de subsistemas del núcleo, controladores propios de Windows y algunos controladores de terceros. Déjanos por aquí las primeras líneas de la pantalla de Poolmon.[/url]


Supongo que tendré que instalar el paquete de herramientas de depuración (Debugging Tools for Windows). ¿Es correcto?.

Saludos.

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
8 años 7 meses antes #15030 por Asterixco

Califa101 escribió: Después de ordenar la columna DIFF, la fila correspondiente al tag KEY marca 37356, y la segunda correspondiente al tag :NTI marca 6805.

La etiqueta Key corresponde a estructuras muy ligeras, quizá en torno a unos 100 bytes de media, con las que Windows gestiona el acceso a claves del registro. Su número puede llamar la atención, incluso lo veo un poco excesivo, pero no debe de representar un consumo de memoria significativo. Olvidé mencionar que también hay que tener muy en cuenta el valor de Bytes. ¿En qué situación estaba el sistema cuando tomaste esos datos?

La otra etiqueta es desconocida. Ahí sí es importante saber la ocupación total en bytes para investigar su posible contribución al problema. Intenta localizar su origen probando el procedimiento del artículo 298102. Abre una ventana de símbolo del sistema y escribe "findstr /s /m /l h:NTI \windows\system32\drivers\*.sys". Si no da resultado, prueba en otras ubicaciones como "\windows\system32\*.sys" o "\archivos de programa\*.sys". El parámetro /S de Findstr recorre subdirectorios, el /M solamente muestra el archivo si se encuentra una coincidencia (no queremos que la emisión accidental de código máquina, aparte de "ensuciar", dé lugar a un desagradable concierto de pitidos), y /L especifica una cadena literal que diferencia mayúsculas y minúsculas, por lo que la etiqueta tiene que aparecer tal cual. La fiabilidad de este método no es muy alta, pues el patrón buscado podría aparecer en un archivo por casualidad, pero es mejor que nada.

¿Puedes hacer más mediciones y pegar las primeras líneas de la pantalla? Las dos de la cabecera y más o menos las primeras diez filas de la tabla. Por ejemplo, nada más iniciar la sesión y después de llevar varios minutos en funcionamiento.

Califa101 escribió: Supongo que tendré que instalar el paquete de herramientas de depuración (Debugging Tools for Windows). ¿Es correcto?.

Es recomendable, aunque por el momento no es necesario.

Ramón Sola | Málaga (España)

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
8 años 7 meses antes - 8 años 7 meses antes #15088 por Califa101

Asterixco escribió:

Califa101 escribió: La etiqueta Key corresponde a estructuras muy ligeras, quizá en torno a unos 100 bytes de media, con las que Windows gestiona el acceso a claves del registro. Su número puede llamar la atención, incluso lo veo un poco excesivo, pero no debe de representar un consumo de memoria significativo. Olvidé mencionar que también hay que tener muy en cuenta el valor de Bytes. ¿En qué situación estaba el sistema cuando tomaste esos datos?


No tenía ninguna aplicación abierta, salvo las típicas y básicas, antivirus, controladores básicos, servicios básicos, etc. Si te hace falta, te las envío.

Asterixco escribió:

Califa101 escribió: La otra etiqueta es desconocida. Ahí sí es importante saber la ocupación total en bytes para investigar su posible contribución al problema. Intenta localizar su origen probando el procedimiento del artículo 298102. Abre una ventana de símbolo del sistema y escribe "findstr /s /m /l h:NTI \windows\system32\drivers\*.sys".


Después de aplicar este comando, el resultado es:
C:\windows\system32\drivers\bdfsfltr.sys
FINDSTR: No se puede abrir C:\windows\system32\drivers\sptd.sys

Asterixco escribió:

Califa101 escribió: ¿Puedes hacer más mediciones y pegar las primeras líneas de la pantalla? Las dos de la cabecera y más o menos las primeras diez filas de la tabla. Por ejemplo, nada más iniciar la sesión y después de llevar varios minutos en funcionamiento.


Aquí te dejo dos archivos:

- Volcado 1.bmp contiene el volcado de pantalla de POOLMON nada mas iniciar Windows.
- Volcado 2.bmp, idem pero unos 30 minutos despues.



Archivo adjunto Volcado1.JPG no encontrado



Archivo adjunto Volcado2.JPG no encontrado

Adjuntos:
Última Edición: 8 años 7 meses antes por Califa101.

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
8 años 7 meses antes #15109 por Asterixco
Las instantáneas no me llevan a ninguna conclusión, pero me preocupa ese consumo alto de memoria no paginada al inicio y los 8,5 megabytes de MmCm en dicha área; incluso quitándolos, los 36-40 MB que quedan me siguen pareciendo demasiados. Lamentablemente, la etiqueta MmCm (Memory Manager - Contiguous Memory) corresponde a cierto tipo de solicitudes de bloques de memoria no paginada que, por la forma en que se atienden, son díficiles de rastrear. Por otra parte, en el área paginada consta la etiqueta Gh05 como "gran consumidora" con unos 15 MB asignados (los Gh?? indican objetos del sistema gráfico de Windows); tal consumo debería ser coherente con la ejecución de aplicaciones que por ejemplo muchas imágenes aunque sea de forma interna, quizá haya que vigilarlo. Las etiquetas Ntf? pertenecen a estructuras de datos del controlador Ntfs.sys para manejar el sistema de archivos NTFS; dado el relativamente gran número de objetos de archivo (File) ocupados, esas apariciones también parecen congruentes.

Según veo, el controlador Bdfsfltr.sys se asocia al antivirus Bit Defender. Como resultado de la búsqueda suponemos que es el responsable de la etiqueta :NTI. Análogamente, las otras etiquetas que empiezan por dos puntos también podrían pertenecer a él. En cuanto al Sptd.sys que "no se puede abrir", suele acompañar a determinadas aplicaciones de grabación o emulación de unidades de CD o DVD (fundamentalmente para montar archivos ISO) como Daemon Tools o Alcohol. Findstr emite el mensaje porque aparentemente el controlador se protege a sí mismo de intentos de inspección o manipulación. Sptd.sys puede o no estar implicado en el rompecabezas que intentamos resolver, aunque no es rara su aparición en según qué informes de fallos extraños e inestabilidades. En cualquier caso, no se puede culpar aún a ninguno de los dos controladores mencionados hasta tener más datos. Eso sí, insisto en que la presencia del tal Sptd.sys me mosquea un poco.

Vamos a cambiar momentáneamente de táctica. ¿El otro día te dije que no hacía falta por el momento instalar el paquete Debugging Tools for Windows ? Pues ahora vamos a usarlo. Microsoft, en su infinita sabiduría (sarcasmo), ha integrado la última versión (6.12.2.633) en el SDK de Windows y no la ofrece en forma de descarga directa. En general funciona bien pero he visto un par de fallitos que hacen que muestre información errónea en algunas ocasiones. Para este propósito nos vale instalar la versión anterior, 6.11.1.404 (x86) .

Crea en primer lugar una carpeta en C:\ que se llame Simbolos, por ejemplo. Esta carpeta estará destinada a albergar los archivos de depuración. Entonces, abre WinDbg desde Inicio, Programas, Microsoft, Debugging Toold for Windows (x86), WinDbg. Si durante el proceso te sale alguna ventana de "Save workspace", di que sí. Ve a File, Symbol File Path, y pega lo siguiente, sin espacios, tabulaciones o saltos de línea ni delante ni detrás:
srv*C:\Simbolos*http://msdl.microsoft.com/download/symbols
Otra opción es configurar la variable de entorno _NT_SYMBOL_PATH con el mismo contenido en Panel de control, Sistema, Opciones avanzadas, Variables de entorno. De un modo u otro, solamente es necesario hacerlo una sola vez, puesto que queda guardado para usos futuros.

Luego ve a File, Kernel Debug. Pincha la pestaña Local y después Aceptar. Esto activará la depuración local del núcleo de Windows, una acción potencialmente peligrosa para la estabilidad del sistema si no se emplea de forma correcta. Para evitar sustos, cierra todas las aplicaciones en las que tengas datos importantes que puedan dañarse o no ser totalmente recuperables si el sistema falla repentinamente. La alternativa menos frágil sería usar la herramienta LiveKd de Sysinternals (necesita residir en la misma carpeta de las herramientas de depuración). Un inconveniente de LiveKd es que genera una instantánea del momento en que se ejecuta, como si fuera un volcado de memoria, por tanto no se actualiza en tiempo real. En caso de querer datos actualizados se debe cerrar el depurador, con lo que LiveKd preguntará si se desea iniciar otra sesión de depuración. El otro problema es que para abrir el depurador gráfico WinDbg a través de LiveKd se necesita el parámetro -w por línea de comandos o por acceso directo, ya que de forma predeterminada arranca el depurador KD basado en texto (si lo inicias accidentalmente, sal con la orden Q).

Cuando está activado el modo de depuración local, el indicador muestra lkd>, mientras que con LiveKd aparece kd> pues funciona como si se depurara un volcado convencional del núcleo. Si Windows no se ha iniciado en el modo de depuración (disponible pulsando la tecla F8 en el arranque del equipo, junto con las opciones de modo seguro, última configuración buena conocida y demás), la depuración local muestra el siguiente aviso:

*******************************************************************************
WARNING: Local kernel debugging requires booting with kernel
debugging support (/debug or bcdedit -debug on) to work optimally.
*******************************************************************************

No nos afecta mucho en lo que vamos a hacer. Entonces escribe:

!vm 1
!poolused /t 15 2
!poolused /t 15 4

La orden !vm 1 exhibe estadísticas de memoria virtual. Los !poolused /t 20 2 y 4 muestran las 20 mayores ocupaciones de pool por etiquetas (con el 2 bloque no paginado y con el 4 paginado). Puedes abandonar la depuración local cerrando WinDbg o por menú Debug, Stop Debugging.

¿Y todo este rollo? Querría que ejecutaras las órdenes anteriores y enviaras los resultados en tres ocasiones: poco después de iniciar Windows, un tiempo más tarde (media hora, una hora... simplemente para comparar los valores) y en cuanto aparezca el primer error 1450 al intentar el service pack. Sí, te pido que intentes de nuevo la instalación.

Ramón Sola | Málaga (España)

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Tiempo de carga de la página: 0.492 segundos
Gracias a Foro Kunena