none
Unable to get the symbols file for wow64cpu.dll from 64-bit Windows 2003 Server SP2

    Question

  • I'm having a dump of a 32-bit process that was executing on 64-bit Windows 2003 Server SP2.

    I've discovered that every thread of the process ends up it's call stack in wow64cpu.dll . Here is the example:
    wow64cpu.dll!0000000078b83f01()
    [Frames below may be incorrect and/or missing, no symbols loaded for wow64cpu.dll]
    wow64.dll!0000000078be6a5a()


    I've got 3 libraries from that OS:

    • wow64win.dll
    • wow64.dll
    • wow64cpu.dll

    I've downloaded the symbols files (*.pdb) from http://msdl.microsoft.com/download/symbols for the first 2 libraries. Here is the same call stack after loading symbols for the wow64.dll:
    wow64cpu.dll!0000000078b83f01()
    [Frames below may be incorrect and/or missing, no symbols loaded for wow64cpu.dll]
    wow64.dll!RunCpuSimulation() + 0xa bytes

    But I can't get the one for the third - wow64cpu.dll. I've tried that in different ways. At first, by using Visual Studio (2008), and then by using symchk from 64-bit Debugging Tools, running on 64-bit Windows Server 2008. All with the same result: no symbols file.
     

    While using symchk on 64-bit Windows Server 2008, I've tried to donwload symbols for the local wow64cpu.dll (i.e. the one that is included in Windows Server 2008) - and have succeeded.

    Here are the outputs form symchk for both libraries: the one for the 2003's library:

    C:\Program Files\Debugging Tools for Windows (x64)>symchk d:\temp\000\wow64cpu.dll /s srv*d:\temp\symbols*http://msdl.microsoft.com/download/symbols /oc d:\temp\000

    SYMCHK: wow64cpu.dll   FAILED - wow64cpu.pdb mismatched or not found

    SYMCHK: FAILED files = 1
    SYMCHK: PASSED + IGNORED files = 0


    ... and the one the 2008's library:

    C:\Program Files\Debugging Tools for Windows (x64)>symchk C:\Windows\System32\wow64cpu.dll /s srv*d:\temp\symbols*http://msdl.microsoft.com/download/symbols /oc d:\temp\000

    SYMCHK: FAILED files = 0
    SYMCHK: PASSED + IGNORED files = 1


    Here is the attributes for wow64cpu.dll from Windows 2003:
    File Version: 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
    Product Version: 5.2.3790.3959
    Modification date: 15 March 2007, 16:00:00


    So, the questions are:

    • where is the symbols file?
    • how to get it?
    Saturday, February 05, 2011 8:45 AM

All replies

  • Hi,

    try to download the symbols package for the host windows at http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx and install it in c:\symbols

    Change the symbol path to SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

    Debug in the same version of OS of host that produce dump.

     


    - Andrea Bianchi - site: http://www.BianchiAndrea.com
    Monday, February 07, 2011 3:01 PM
  • I've forgot to mension that I've tried to download that symbols packages.

    Some of them do not contain that .pdb-file. Others do, but that wow64cpu.dll.pdb's  do not match to the wow64cpu.dll I have.

    Please notice that I have successfully downloaded symbols for two other libraries from that OS: wow64win.dll and wow64.dll.

    Anyway, that OS is practically inaccessable: it's thousands kilometers away and without any external access to it; neither I have a distribution disk of it.

    Tuesday, February 08, 2011 5:05 AM
  • You can force the symbol loading for a specific pdb, but your debug result is wrong for this (line code can mismatch)

    use:

    .reload /f [name] /i


    - Andrea Bianchi - site: http://www.BianchiAndrea.com
    Wednesday, February 09, 2011 8:50 AM
  • You can force the symbol loading for a specific pdb, but your debug result is wrong for this (line code can mismatch)

    use:

    .reload /f [name] /i


    - Andrea Bianchi - site: http://www.BianchiAndrea.com

    That's why this woun't suit :-)
    Wednesday, February 09, 2011 9:35 AM
  • Hi,

    Use WinDBG x86 to view the call stack of a 32-bit process.


    Csaba

    Sunday, July 01, 2012 9:01 AM
  • hi!

    did this problem resolved? I met same situation.

    Monday, September 24, 2012 5:28 AM