dx command of windbg is strange when a dmp of windbg from volatility raw2dmp is analyzed RRS feed

  • Question

  • I got Windows7x64's memory, and then translated the dmp of windbg by volatility's raw2dmp.
    I opened the dmp by windbg.
    Then I typed the


    the rsp was normal,

    16.0: kd> r rsp
    Last set context:

    But when I dx the address, windbg was quite strange.

    16.0: kd> da fffff8800817d1c0
    0000:d1c0 "????????????????????????????????"
    0000:d1e0 "????????????????????????????????"
    0000:d200 "????????????????????????????????"
    0000:d220 "????????????????????????????????"

    It seemed that windbg deal the address as 16bit number either 64bit number.
    I was sure that the stack memory was good because kb could show the frames and retaddr.
    Could you help me?

    Friday, May 22, 2020 7:32 AM

All replies

  • Why do you use "wow64exts.sw"?  That shouldn't matter at all for a crash dump.  The "16.0>" prompt tells you it thinks its debugging a 16-bit process.

    A memory dump doesn't contain any information about CPUs.  How could raw2dmp have any notion about the registers?

    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Friday, May 22, 2020 10:54 PM
  • Are you sure, volatility is working flawlessly, when converting the raw memory into Microsoft crash-dump?
    Did you choose the correct "--profile"?

    With kind regards
    Saturday, May 23, 2020 9:06 AM
  • Thank you!

    As we know, there are many versiones of the ntoskrnl.exe.

    In this case, the version is 7601.245XX. But the lastest supportment is 7601.24000 from the volatility 2.6.1 .

    Should there be some bug of the volatility?

    Friday, June 5, 2020 6:35 AM
  • Basically it's not clear to me, what you are really doing.
    Why are you using this !wow64exts.sw in the first place?
    Is windbg not realizing that it's a 64bit dump? Why do you try to switch between 32/64 bit mode?
    Being not really an expert here, but if in need to switch between x64 (AMD64) and x86 for e.g. displaying a 32-bit user-mode stack, then this seems not to look that bad to me (here notepad x86 process, live kernel x64 debugging please notice the debugger prompt: kd:x86>/ kd>) :

    kd> .thread /r /p /w ffffb08640e78080
    Implicit thread is now ffffb086`40e78080
    Implicit process is now ffffb086`3fec4080
    .cache forcedecodeuser done
    Loading User Symbols
    Loading Wow64 Symbols
    The context is partially valid. Only x86 user-mode context is available.
    x86 context set
    kd:x86> k
      *** Stack trace for last set context - .thread/.cxr resets it
    ChildEBP          RetAddr           
    02b1fb14 76b93db0 win32u!NtUserGetMessage+0xc
    02b1fb50 00907b8b USER32!GetMessageW+0x30
    02b1fbc0 0091c0e0 notepad!WinMain+0x15a
    02b1fc50 77010179 notepad!__mainCRTStartup+0x146
    02b1fc60 77e5662d KERNEL32!BaseThreadInitThunk+0x19
    02b1fcbc 77e565fd ntdll_77df0000!__RtlUserThreadStart+0x2f
    02b1fccc 00000000 ntdll_77df0000!_RtlUserThreadStart+0x1b

    and when going back:

    kd:x86> .effmach #
    Effective machine: x64 (AMD64)
    kd> .thread /r /p ffffb08640e78080
    Implicit thread is now ffffb086`40e78080
    Implicit process is now ffffb086`3fec4080
    .cache forcedecodeuser done
    Loading User Symbols
    Loading Wow64 Symbols
    kd> da ffffee57`b1a33488
    ffffee57`b1a33488  "....tbH..H.."
    kd> k
      *** Stack trace for last set context - .thread/.cxr resets it
    Child-SP          RetAddr           Call Site
    fffff38c`bd0fb080 fffff804`2811f6c7 nt!KiSwapContext+0x76
    fffff38c`bd0fb1c0 fffff804`2811f239 nt!KiSwapThread+0x297
    fffff38c`bd0fb280 fffff804`2811dfc0 nt!KiCommitThreadWait+0x549
    fffff38c`bd0fb320 fffff804`2811c9c4 nt!KeWaitForSingleObject+0x520
    fffff38c`bd0fb3f0 ffffee57`b1a338ab nt!KeWaitForMultipleObjects+0x44
    fffff38c`bd0fb4c0 ffffee57`b1a33488 win32kfull!xxxRealSleepThread+0x36b
    fffff38c`bd0fb5d0 ffffee57`b1a35298 win32kfull!xxxSleepThread2+0xac
    fffff38c`bd0fb620 ffffee57`b1a33ce2 win32kfull!xxxRealInternalGetMessage+0xa98
    fffff38c`bd0fba60 fffff804`281ca785 win32kfull!NtUserGetMessage+0x92
    fffff38c`bd0fbb00 00007ffd`e021f524 nt!KiSystemServiceCopyEnd+0x25
    00000000`02ade1a8 00007ffd`e021338e wow64win!NtUserGetMessage+0x14
    00000000`02ade1b0 00007ffd`e0667783 wow64win!whNtUserGetMessage+0x2e
    00000000`02ade210 00000000`77de1783 wow64!Wow64SystemServiceEx+0x153
    00000000`02adead0 00000000`77de1199 wow64cpu!ServiceNoTurbo+0xb
    00000000`02adeb80 00007ffd`e066cf9a wow64cpu!BTCpuSimulate+0x9
    00000000`02adebc0 00007ffd`e066ce60 wow64!RunCpuSimulation+0xa
    00000000`02adebf0 00007ffd`e29d5b3d wow64!Wow64LdrpInitialize+0x120
    00000000`02adeea0 00007ffd`e29c3779 ntdll!LdrpInitializeProcess+0x1789
    00000000`02adf2e0 00007ffd`e29756a3 ntdll!_LdrpInitialize+0x4e0bd
    00000000`02adf380 00007ffd`e297564e ntdll!LdrpInitialize+0x3b
    00000000`02adf3b0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
    No warranty
    With kind regards

    Friday, June 5, 2020 8:21 PM
  • The dump file was transformed by volatility's plugin named raw2dmp. When I opened the dmp by windbg, it showed that "16.0: kd:x86". So I had to typed "wow64exts.sw".

    I think you are right, windbg thought this is a 16-bit process.

    Could you give me some advertisement?

    Sunday, June 28, 2020 8:57 AM
  • For me, this appears to be a kind of

    You already searched in / approached

    Are you able to achieve your goals with builtin volatility commands or plugins working on the raw dump?

    With kind regards 
    Sunday, June 28, 2020 12:42 PM