Note: 32-bit stack from 64-bit dump

Just a short note that might be useful if you get a 64-bit dump of a 32-bit process from x64 Windows. As a reminder I wrote already about separate dump types and tools for 32-bit and 64-bit processes.

Since then I’ve been looking for a simple solution in case we get a 64-bit dump so we could look at 32-bit thread stacks, etc. Yesterday I accidentally found wow64exts.dll extension in 64-bit WinDbg. I should have been looked at \winxp folder before :-) 

The whole discussion and solution can be found on Crash Dump Analysis forum:

http://www.dumpanalysis.org/forum/viewtopic.php?t=39

Now if by accident a customer sends a 64-bit dump of a 32-bit process (some Citrix services like IMA service are still 32-bit in x64 CPS4) then we can look at threads without asking for a new dump and therefore avoid roundtrips and shorten time to problem resolution.

- Dmitry Vostokov -

4 Responses to “Note: 32-bit stack from 64-bit dump”

  1. Skywing Says:

    The preferred way to do this is “.effmach x86″, btw; then use “.effmach .” to return to the native processor mode.

    The builtin engine commands supersede the older wow64exts extension dll.

  2. Dmitry Vostokov Says:

    Thanks, it works, but it still uses wow64exts

    0:000> .effmach x86
    Effective machine: x86 compatible (x86)
    0:000:x86> ~*kv

    . 0 Id: 9ac.d7c Suspend: 0 Teb: 00000000`7efdb000 Unfrozen
    Need to load wow64exts.dll to retrieve context!

  3. Dmitry Vostokov Says:

    Moreover you you need to load that extention manually:

    1 Id: 9ac.668 Suspend: 0 Teb: 00000000`7efad000 Unfrozen
    Need to load wow64exts.dll to retrieve context!
    ChildEBP RetAddr Args to Child
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0010001f 00000000 00000000 00000000 00000000 0×0

    0:000:x86> .load wow64exts
    0:000:x86> ~*kv


    1 Id: 9ac.668 Suspend: 0 Teb: 00000000`7efad000 Unfrozen
    ChildEBP RetAddr Args to Child
    03a0fad8 7db40553 00000270 00000001 03a0fb00 ntdll_7d600000!ZwWaitForSingleObject+0×15
    03a0fb14 7db4092c 00000270 0000027c 00000000 mswsock!SockWaitForSingleObject+0×19d
    03a0fc04 71c0470c 00000001 03a0fe84 03a0fc7c mswsock!WSPSelect+0×380
    03a0fc54 77215d7a 00000001 03a0fe84 03a0fc7c WS2_32!select+0xb9
    03a0ffb0 7721d925 03a0ffec 7d4dfff1 003349e8 WININET!ICAsyncThread::SelectThread+0×22a
    03a0ffb8 7d4dfff1 003349e8 00000000 00000000 WININET!ICAsyncThread::SelectThreadWrapper+0xd
    03a0ffec 00000000 7721d918 003349e8 00000000 kernel32!BaseThreadStart+0×34

  4. Crash Dump Analysis » Blog Archive » Reflecting on 2008 (Part 1) Says:

    […] flow analysis was incomplete, some code may be missing wanarpv6 ldrpcallinitroutine windbg scripts wow64exts debug_flr_image_timestamp userdump debug crash analyzer dumpanalysis vdtw30.dll windbg 64 bits dump […]

Leave a Reply

You must be logged in to post a comment.