Comprobar símbolos

Artículo
04/14/2023

Los problemas de símbolos pueden aparecer de varias maneras. Quizás un seguimiento de pila muestre información incorrecta o no identifique los nombres de las funciones de la pila. O quizás un comando del depurador no pudo comprender el nombre de un módulo, una función, una variable, una estructura o un tipo de datos.

Si sospecha que el depurador no está cargando correctamente los símbolos, hay varios pasos que puede seguir para investigar este problema.

En primer lugar, use el comando lm (Enumerar módulos cargados) para mostrar la lista de módulos cargados con información de símbolos. La forma más útil de este comando es la siguiente:

0:000> lml

Si usa WinDbg, depurar | El comando de menú Módulos también le permitirá ver esta información.

Preste especial atención a las notas o abreviaturas que pueda ver en estas pantallas. Para obtener una interpretación de estas, vea Abreviaturas de estado de símbolos.

Si no ve los archivos de símbolos adecuados, lo primero que debe hacer es comprobar la ruta de acceso del símbolo:

0:000> .sympath
Current Symbol Path is: d:\MyInstallation\i386\symbols\retail

Si la ruta de acceso del símbolo es incorrecta, corrijala. Si usa el depurador de kernel, asegúrese de que el %WINDIR% local no está en la ruta de acceso del símbolo.

A continuación, vuelva a cargar símbolos mediante el comando .reload (Módulo de recarga ):

0:000> .reload ModuleName

Si la ruta de acceso del símbolo es correcta, debe activar el modo ruidoso para que pueda ver qué archivos de símbolos dbghelp se está cargando. A continuación, vuelva a cargar el módulo. Consulte Establecer opciones de símbolos para obtener información sobre cómo activar el modo ruidoso.

Este es un ejemplo de una recarga "ruidosa" de los símbolos de Microsoft Windows:

kd> !sym noisy
kd> .reload nt
 1: Kernel Version 2081 MP Checked
 2: Kernel base = 0x80400000 PsLoadedModuleList = 0x80506fa0
 3: DBGHELP: FindExecutableImageEx-> Looking for D:\MyInstallation\i386\ntkrnlmp.exe...mismatched timestamp
 4: DBGHELP: No image file available for ntkrnlmp.exe
 5: DBGHELP: FindDebugInfoFileEx-> Looking for
 6: d:\MyInstallation\i386\symbols\retail\symbols\exe\ntkrnlmp.dbg... no file
 7: DBGHELP: FindDebugInfoFileEx-> Looking for
 8: d:\MyInstallation\i386\symbols\retail\symbols\exe\ntkrnlmp.pdb... no file
 9: DBGHELP: FindDebugInfoFileEx-> Looking for d:\MyInstallation\i386\symbols\retail\exe\ntkrnlmp.dbg... OK
10: DBGHELP: LocatePDB-> Looking for d:\MyInstallation\i386\symbols\retail\exe\ntkrnlmp.pdb... OK
11: *** WARNING: symbols checksum and timestamp is wrong 0x0036a4ea 0x00361a83 for ntkrnlmp.exe

El controlador de símbolos busca primero una imagen que coincida con el módulo que intenta cargar (líneas tres y cuatro). La propia imagen no siempre es necesaria, pero si hay una incorrecta, el controlador de símbolos a menudo producirá un error. Estas líneas muestran que el depurador encontró una imagen en D:\MyInstallation\i386\ntkrnlmp.exe, pero la marca de fecha y hora no coincide. Dado que la marca de fecha y hora no coincide, la búsqueda continúa. A continuación, el depurador busca un archivo .dbg y un archivo .pdb que coincida con la imagen cargada. Se encuentran en las líneas 6 a 10. La línea 11 indica que, aunque se cargaron símbolos, la marca de fecha y hora de la imagen no coincidía (es decir, los símbolos eran incorrectos).

Si la búsqueda de símbolos encontró un error catastrófico, verá un mensaje del formulario:

ImgHlpFindDebugInfo(00000000, module.dll, c:\MyDir;c:\SomeDir, 0823345, 0) failed

Esto puede deberse a elementos como errores del sistema de archivos, errores de red y archivos .dbg dañados.

Diagnóstico de errores de carga de símbolos

Cuando está en modo ruidoso, el depurador puede imprimir códigos de error cuando no puede cargar un archivo de símbolos. Los códigos de error de los archivos .dbg se enumeran en winerror.h. Los códigos de error .pdb proceden de otro origen y los errores más comunes se imprimen en texto en inglés sin formato.

Algunos códigos de error comunes para los archivos .dbg de winerror.h son:

0xB
ERROR_BAD_FORMAT

0x3
ERROR_PATH_NOT_FOUND

0x35
ERROR_BAD_NETPATH

Es posible que no se pueda cargar el archivo de símbolos debido a un error de red. Si ve ERROR_BAD_FORMAT o ERROR_BAD_NETPATH y está cargando símbolos desde otra máquina de la red, intente copiar el archivo de símbolos en el equipo host y coloque su ruta de acceso en la ruta de acceso del símbolo. A continuación, intente volver a cargar los símbolos.

Comprobación de la ruta de acceso y los símbolos de búsqueda

Let "c:\MyDir; c:\SomeDir" representa la ruta de acceso del símbolo. ¿Dónde debe buscar información de depuración?

En los casos en los que el archivo binario se ha quitado de la información de depuración, como las compilaciones gratuitas de Windows, busque primero un archivo .dbg en las siguientes ubicaciones:

c:\MyDir\symbols\exe\ntoskrnl.dbg
c:\SomeDir\symbols\exe\ntoskrnl.dbg
c:\MyDir\exe\ntoskrnl.dbg
c:\SomeDir\exe\ntoskrnl.dbg
c:\MyDir\ntoskrnl.dbg
c:\SomeDir\ntoskrnl.dbg
current-working-directory\ntoskrnl.dbg

A continuación, busque un archivo .pdb en las siguientes ubicaciones:

c:\MyDir\symbols\exe\ntoskrnl.pdb
c:\MyDir\exe\ntoskrnl.pdb
c:\MyDir\ntoskrnl.pdb
c:\SomeDir\symbols\exe\ntoskrnl.pdb
c:\SomeDir\exe\ntoskrnl.pdb
c:\SomeDir\ntoskrnl.pdb
current-working-directory\ntoskrnl.pdb

Tenga en cuenta que en la búsqueda del archivo .dbg, el depurador intercala la búsqueda en los directorios MyDir y SomeDir, pero en la búsqueda .pdb no.

Windows XP y versiones posteriores de Windows no usan ningún archivo de símbolos .dbg. Consulte Símbolos y archivos de símbolos para obtener más información.

Compilaciones no coincidentes

Uno de los problemas más comunes en los errores de depuración en un equipo que a menudo se actualiza son símbolos no coincidentes de diferentes compilaciones. Tres causas comunes de este problema son: apuntar a símbolos para la compilación incorrecta, usar un binario creado de forma privada sin los símbolos correspondientes y usar el nivel de abstracción de hardware de un procesador (HAL) y los símbolos de kernel en una máquina multiprocesador. Los dos primeros son simplemente una cuestión de hacer coincidir los archivos binarios y los símbolos; la tercera se puede corregir cambiando el nombre de hal*.dbg y ntkrnlmp.dbg a hal.dbg y ntoskrnl.dbg.

Para averiguar qué compilación de Windows está instalada en el equipo de destino, use el comando vertarget (Mostrar versión del equipo de destino):

kd> vertarget 
Windows XP Kernel Version 2505 UP Free x86 compatible
Built by: 2505.main.010626-1514
Kernel base = 0x804d0000 PsLoadedModuleList = 0x80548748
Debug session time: Mon Jul 02 14:41:11 2001
System Uptime: 0 days 0:04:53

Probar los símbolos

Probar los símbolos es más difícil. Implica comprobar un seguimiento de pila en el depurador y ver si la salida de depuración es correcta. Este es un ejemplo para probar:

kd> u videoprt!videoportfindadapter2
Loading symbols for 0xf2860000     videoprt.sys ->   videoprt.sys

VIDEOPRT!VideoPortFindAdapter2:
f2856f42 55               push    ebp
f2856f43 8bec             mov     ebp,esp
f2856f45 81ecb8010000     sub     esp,0x1b8
f2856f4b 8b4518           mov     eax,[ebp+0x18]
f2856f4e 53               push    ebx
f2856f4f 8365f400         and     dword ptr [ebp-0xc],0x
f2856f53 8065ff00         and     byte ptr [ebp-0x1],0x0
f2856f57 56               push    esi

El comando u desemba la cadena videoportfindadapter en videoprt.sys. Los símbolos son correctos en el depurador porque los comandos comunes de pila como push y mov se muestran en la pila. La mayoría de las funciones comienzan con una operación add, sub o push mediante el puntero base (ebp) o el puntero de pila (esp).

Normalmente es obvio cuando los símbolos no funcionan correctamente. Glintmp.sys no tiene símbolos en este ejemplo porque una función no aparece junto a Glintmp:

kd> kb
Loading symbols for 0xf28d0000     videoprt.sys ->   videoprt.sys
Loading symbols for 0xf9cdd000      glintmp.sys ->   glintmp.sys
*** ERROR: Symbols could not be loaded for glintmp.sys
ChildEBP RetAddr  Args to Child
f29bf1b0 8045b5fa 00000001 0000a100 00000030 ntoskrnl!RtlpBreakWithStatusInstruction
f29bf1b0 8044904e 00000001 0000a100 00000030 ntoskrnl!KeUpdateSystemTime+0x13e
f29bf234 f28d1955 f9b7d000 ffafb2dc f9b7d000 ntoskrnl!READ_REGISTER_ULONG+0x6
f29bf248 f9cde411 f9b7d000 f29bf2b0 f9ba0060 VIDEOPRT!VideoPortReadRegisterUlong+0x27
00000002 00000000 00000000 00000000 00000000 glintMP+0x1411 [No function listed.]

Los símbolos de compilación incorrectos se cargaron para este seguimiento de pila. Observe cómo no hay funciones enumeradas para las dos primeras llamadas. Este seguimiento de pila es similar a un problema con win32k.sys rectángulos de dibujo:

1: kd> 
1: kd> kb                      [Local        9:50 AM]
Loading symbols for 0xf22b0000       agpcpq.sys ->   agpcpq.sys
*** WARNING: symbols checksum is wrong 0x0000735a 0x00000000 for agpcpq.sys
*** ERROR: Symbols could not be loaded for agpcpq.sys
Loading symbols for 0xa0000000       win32k.sys ->   win32k.sys
*** WARNING: symbols checksum is wrong 0x00191a41 0x001995a9 for win32k.sys
ChildEBP RetAddr  Args to Child
be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ+0x125b [No function listed.]
be682b4c a0140dd4 826a72f0 e11410a8 a0139605 agpCPQ+0x372b [No function listed.]
be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k!vPatCpyRect1_6x6+0x20b
00000001 00000000 00000000 00000000 00000000 win32k!RemoteRedrawRectangle+0x32

Este es el seguimiento de pila correcto. El problema es realmente con AGP440.sys. El primer elemento que aparece en un seguimiento de pila suele estar en error. Observe que el error de win32k.sys rectángulo ha desaparecido:

1: kd> kb                      [Local        9:49 AM]
ChildEBP RetAddr  Args to Child
be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ!AgpReleaseMemory+0x88
be682b30 f20a385c 82703638 e183ec68 00000000 agpCPQ!AgpInterfaceReleaseMemory+0x8b
be682b4c a0140dd4 826a72f0 e11410a8 a0139605 VIDEOPRT!AgpReleasePhysical+0x44
be682b58 a0139605 e1cee560 e11410a8 a00e5f0a win32k!OsAGPFree+0x14
be682b64 a00e5f0a e1cee560 e11410a8 e1cee560 win32k!AGPFree+0xd
be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k!HeapVidMemFini+0x49
be682b9c a00f5c20 e1cee008 e1cee008 be682c0c win32k!vDdDisableDriver+0x3a
be682bac a00da510 e1cee008 00000000 be682c0c win32k!vDdDisableDirectDraw+0x2d
be682bc4 a00da787 00000000 e1843df8 e1843de8 win32k!PDEVOBJ__vDisableSurface+0x27
be682bec a00d59fb 00000000 e1843de8 00000000 win32k!PDEVOBJ__vUnreferencePdev+0x204
be682c04 a00d7421 e1cee008 82566a98 00000001 win32k!DrvDestroyMDEV+0x30
be682ce0 a00a9e7f e1843e10 e184a008 00000000 win32k!DrvChangeDisplaySettings+0x8b3
be682d20 a008b543 00000000 00000000 00000000 win32k!xxxUserChangeDisplaySettings+0x106
be682d48 8045d119 00000000 00000000 00000000 win32k!NtUserChangeDisplaySettings+0x48
be682d48 77e63660 00000000 00000000 00000000 ntkrnlmp!KiSystemService+0xc9

Comandos y extensiones útiles

Los siguientes comandos y extensiones pueden ser útiles para realizar un seguimiento de los problemas de símbolos:

lm (Enumerar módulos cargados)
Enumera todos los módulos y proporciona el estado de carga de todos los símbolos de estos módulos.

!dh image-header-base
Muestra información de encabezado para una imagen cargada que comienza en image-header-base.

.reload /n
Vuelve a cargar todos los símbolos del kernel.

.reload [image-name]
(Solo CDB o WinDbg) Vuelve a cargar símbolos para el nombre de la imagen. Si no se especifica ningún nombre de imagen , vuelve a cargar símbolos para todas las imágenes. (Es necesario volver a cargar símbolos después de cambiar la ruta de acceso del símbolo).

!sym ruidoso
Activa el modo detallado para las cargas de símbolos. Esto se puede usar para obtener información sobre las cargas del módulo. Consulte Configuración de opciones de símbolos para obtener más información.

.simpat [new-symbol-path]
Establece una nueva ruta de acceso de símbolo o muestra la ruta de acceso del símbolo actual. Consulte Ruta de acceso de símbolos para obtener más información.

Si los símbolos del kernel son correctos, pero no obtiene una pila completa, los siguientes comandos también pueden ser útiles:

¡X*!
Esto enumerará los módulos que actualmente tienen símbolos cargados. Esto resulta útil si los símbolos del kernel son correctos.

.reload /user
Esto intentará volver a cargar todos los símbolos en modo de usuario. Esto es necesario al realizar la depuración del kernel si se cargaron símbolos mientras se estaba ejecutando un proceso y se produjo una interrupción más adelante en otro proceso. En este caso, los símbolos en modo de usuario del nuevo proceso no se cargarán a menos que se ejecute este comando.

X wdmaud!*start\*
Esto mostrará solo los símbolos del módulo wdmaud cuyos nombres contienen la cadena "start". Esto tiene la ventaja de que fuerza la recarga de todos los símbolos en wdmaud, pero solo muestra aquellos con "start" en ellos. (Esto significa una lista más corta, pero dado que siempre hay algunos símbolos con "inicio", habrá alguna comprobación de que se ha realizado la carga).

Otra técnica útil para comprobar que los símbolos no se ensamblan. La mayoría de las funciones comienzan con una operación add, sub o push mediante el puntero base (ebp) o el puntero de pila (esp o sp). Pruebe a desensamblar (función U) algunas de las funciones de la pila (de desplazamiento cero) para comprobar los símbolos.

Problemas de red y puerto

Los problemas se producirán con los archivos de símbolos y al conectarse al depurador. Estas son algunas cosas que debe tener en cuenta si encuentra problemas:

Determine a qué puerto COM está conectado el cable de depuración en el sistema de prueba.
Compruebe la configuración de boot.ini del sistema de prueba. Busque el modificador /debug y compruebe la velocidad de baudios y la configuración del puerto COM.
Los problemas de red pueden interferir con la depuración si se accede a los archivos de símbolos a través de la red.
.dll y .sys archivos con el mismo nombre (por ejemplo , mga64.sys y mga64.dll) confundirán al depurador si no están separados en los directorios adecuados del árbol de símbolos.
El depurador de kernel no siempre le gusta reemplazar los archivos de símbolos de compilación por archivos de símbolos privados. Compruebe la ruta de acceso del símbolo y vuelva a cargarFileName en el símbolo de comportamiento erróneo. El comando !dlls a veces es útil.

Preguntas e ideas erróneas

Q: He cargado correctamente símbolos, pero la pila parece estar equivocada. ¿Se ha roto el depurador?

Un: No necesariamente. La causa más probable de su problema es que tiene símbolos incorrectos. Siga los pasos descritos en esta sección para determinar si ha cargado símbolos válidos o no. No suponga que, dado que algunas cosas funcionan, tiene símbolos válidos. Por ejemplo, puede ejecutar dd nt!nt!ntbuildnumber o u nt! KeInitializeProcess con símbolos incorrectos. Compruebe que son correctos mediante los procedimientos descritos anteriormente.

Q: ¿Seguirá funcionando el depurador con símbolos incorrectos?

Un: Sí y no. A menudo puede escapar con símbolos que no coinciden estrictamente. Por ejemplo, los símbolos de una compilación anterior de Windows a menudo funcionarán en determinados casos, pero no hay ninguna regla en cuanto a cuándo funcionará y cuándo no funcionará.

Q: Estoy detenido en el depurador de kernel y quiero ver símbolos para mi proceso en modo de usuario. ¿Puedo hacerlo?

Un: Principalmente. La compatibilidad con este escenario es deficiente porque el depurador de kernel no mantiene suficiente información sobre cómo realizar el seguimiento de las cargas del módulo para cada proceso, pero hay una solución alternativa razonable. Para cargar símbolos para un módulo en modo de usuario, ejecute un comando .reload -user . Esto cargará los módulos en modo de usuario para el contexto actual.

Q: ¿Qué significa el mensaje siguiente?

*** WARNING: symbols checksum and timestamp is wrong 0x0036d6bf 0x0036ab55 for ntkrnlmp.exe

Un: Significa que los símbolos de ntkrnlmp.exe son incorrectos.

Compartir a través de