2011-03-17 7 views
5

Estoy intentando volcar la información del montón del archivo de memoria de volcado completo que se encuentra en Windows Server 2003 SP2 x86. Dump se creó para la aplicación mixta (native/clr) de 32 bits que se ejecutaba en la máquina Windows Server 2003 SP2 x64.! Heap failed. Información de tipo no válida para ntdll! _HEAP_ENTRY

En el siguiente registro windbg entiendo que la imagen cargada ntdll.dll es incorrecta y no corresponde a los símbolos ntdll.pdb. He intentado especificar la ubicación de ntdll.dll desde la máquina de destino, pero windbg aún muestra que el módulo se carga desde la ubicación estándar (c: \ windows \ system32).

¿Qué hice mal? Cómo forzar windbg para cargar la versión correcta de ntdll?


Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 

[ ... skipped ... ] 

0:042> vertarget 
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible 
Product: Server, suite: TerminalServer SingleUserTS 
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244) 
Machine Name: 
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5) 
System Uptime: 17 days 10:34:26.068 
Process Uptime: 1 days 15:19:14.000 
    Kernel time: 0 days 1:24:01.000 
    User time: 0 days 22:07:58.000 

0:042> .sympath 
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\__exe;SRV*C\Symbols*http://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols 

0:042> .exepath 
Executable image search path is: C:\__exe;C:\__target\Windows\SysWOW64; 

0:042> .reload 

[ ... skipped ... ] 

0:042> .reload /u ntdll.dll 
Unloaded ntdll.dll 
0:042> .reload /v /f ntdll.dll 
AddImage: C:\WINDOWS\system32\ntdll.dll // why is it still c:\windows\system32 
DllBase = 7d600000 
Size  = 000f0000 
Checksum = 000c371a 
TimeDateStamp = 4cc1831e 

0:042> lm 
[ ... skipped ... ] 
7d600000 7d6f0000 ntdll  (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb 

0:042> !heap 
************************************************************************* 
*** Your debugger is not using the correct symbols     *** 
[ ... skipped ... ] 
*** Type referenced: ntdll!_HEAP_ENTRY        *** 
************************************************************************* 
Invalid type information 

0:042> lmi vm ntdll 
start end  module name 
7d600000 7d6f0000 ntdll  (pdb symbols)   ntdll.dll 
    Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb 
    Image path: C:\WINDOWS\system32\ntdll.dll 
    Image name: ntdll.dll 
    Timestamp:  Fri Oct 22 07:27:10 2010 (4CC1831E) 
    CheckSum:   000C371A 
    ImageSize:  000F0000 
    File version:  5.2.3790.4789 // this is correct and 
    Product version: 5.2.3790.4789 // does correspond to target computer 
    File flags:  0 (Mask 3F) 
    File OS:   40004 NT Win32 
    File type:  2.0 Dll 
    File date:  00000000.00000000 
    Translations:  0409.04b0 
    CompanyName:  Microsoft Corporation 
    ProductName:  MicrosoftR WindowsR Operating System 
    InternalName:  ntdll.dll 
    OriginalFilename: ntdll.dll 
    ProductVersion: 5.2.3790.4789 
    FileVersion:  5.2.3790.4789 (srv03_sp2_gdr.101019-0340) 
    FileDescription: NT Layer DLL 
    LegalCopyright: c Microsoft Corporation. All rights reserved. 

ACTUALIZACIÓN:

que se movió un poco más lejos en mi problema. Logré conectarme al proceso en vivo del lado de los clientes e intenté investigar heap (heap -s) allí y básicamente obtuve el mismo resultado.


(1520.7c4): Wake debugger - code 80000007 (first chance) 
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4 
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0   nv up ei pl nz na po nc 
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b    efl=00000202 
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll - 
ntdll!ZwReadFile+0x15: 
7d61c876 c22400   ret  24h 
0:000> !heap -s 
************************************************************************* 
*** Your debugger is not using the correct symbols     *** 
*** [...skipped...]             *** 
*** Type referenced: ntdll!_HEAP_ENTRY        *** 
************************************************************************* 
Invalid type information 
0:000> .reload 
Reloading current modules 
................................................................ 
.................................... 
0:000> !heap -s 
************************************************************************* 
*** Your debugger is not using the correct symbols     *** 
*** [...skipped...]             *** 
*** Type referenced: ntdll!_HEAP_ENTRY        *** 
************************************************************************* 
Invalid type information 

creo que tengo un problema similar al que se menciona en este artículo http://support.microsoft.com/kb/959207. El entorno y el problema parecen ser los mismos, pero las versiones dll son diferentes, por lo que no es la solución para mí.

Creo que tengo que pasar este problema a Microsoft.

¿Alguien sabe a dónde debería llegar con esta pregunta?

Respuesta

2

La solución parece ser fácil pero no obvia.

  • He encontrado wntdll.pdb un poco más grande que la mía, que contiene símbolos necesarios y vuelva a cargarlo con el comando .Reload/f/i ntdll.dll

  • y tomo la acumulación previa de windbg 6.11.0001.404 , en el actual 6.12.0002.633! El comando heap todavía no funciona en mi caso.

3

Esto podría suceder si el volcado se creó con herramientas de 64 bits. Hay buena información en Tess's blog que explica la razón por la cual importa la bitness del vertedero.

+1

El volcado es de 32 bit. Puedo verlo tratando de cambiarlo al modo de 32 bits en windbg.

 0:042> .load wow64exts 0:042> !sw !wow64exts.sw : command invalid on non-64bit target 
Quizás esta sea la razón (volcado de 32 bits creado en el sistema de 64 bits) por el que no puedo cargar ntdll.dll desde otra ubicación. –

+1

Entonces es otra cosa. Puede confirmar el tipo de módulos con! Lmi (estaba usando lmi sin!, Este es un comando diferente). ! lmi va a volcar Machine Type, que sería I386 o X64. En su caso, debe esperar que "! Lmi ntdll.dll" imprima I386. –

Cuestiones relacionadas