OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9 - [targeting 32bit binary]

[donghyunlee00]

Hi, first of all thank you for providing such a awesome fuzzer:)

I'm trying to use this fuzzer for various targets, but I got an error while OpenDumpFile.

Test Environment

• Host: VMware
  • Windows 10 Pro 21H2 (OS build 19044.1706)
  • Memory 8GB, Processors 2
• Guest: Hyper-V in VMware
  • Windows 10 Pro 21H2 (OS build 19044.1288)
  • Hyper-V generation 1
  • Memory 4GB, Processors 1
• WinDbg Preview
  • KDNET
• Targeting 32bit binary

Attachment

• Target dll file, and exe file which loads it: target.zip
• mem.dmp & regs.json: dump

Error

Master

C:\Users\user\Desktop\workspace\wtf\targets\test>..\..\src\build\wtf.exe master --name test --max_len=1028 --runs=10000000 --target .
Seeded with 14615897280764036030
Iterating through the corpus..
Sorting through the 10 entries..
Running server on tcp://localhost:31337..

Fuzz

C:\Users\user\Desktop\workspace\wtf\targets\test>..\..\src\build\wtf.exe fuzz --backend=bochscpu --name test --limit 10000000
Initializing the debugger instance.. (this takes a bit of time)
OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9  # ERROR!!

---

Those steps were used to obtain the snapshot:

kd> !gflag +ksl
New NtGlobalFlag contents: 0x00040000
    ksl - Enable loading of kernel debugger symbols

kd> sxe ld YYY.dll

kd> g

Make XXX.exe loads YYY.dll through user interaction. (=double click wtf_input.xlsx)

kd> bp YYY+12aec2

kd> g
WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
The context is partially valid. Only x86 user-mode context is available.
YYY+0x12aec2:
00000000`68d2aec2 e84961f8ff      call    YYY+0xb1010 (68cb1010)
The context is partially valid. Only x86 user-mode context is available.

32.kd:x86> .scriptload C:\Users\user\Desktop\tools\bdump\bdump.js
[bdump] Usage: !bdump "C:\\path\\to\\dump"
[bdump] Usage: !bdump_full "C:\\path\\to\\dump"
[bdump] Usage: !bdump_active_kernel "C:\\path\\to\\dump"
[bdump] This will create a dump directory and fill it with a memory and register files
[bdump] NOTE: you must include the quotes and escape the backslashes!
JavaScript script successfully loaded from 'C:\Users\user\Desktop\tools\bdump\bdump.js'

32.kd:x86> !wow64exts.sw
The context is partially valid. Only x86 user-mode context is available.
Switched to Host mode

32.kd> !bdump "C:\\Users\\user\\Downloads\\dump"
[bdump] creating dir...
[bdump] saving regs...
[bdump] register fixups...
[bdump] don't know how to get mxcsr_mask or fpop, setting to zero...
[bdump]
[bdump] don't know how to get avx registers, skipping...
[bdump]
[bdump] tr.base is not cannonical...
[bdump] old tr.base: 0x5cb63000
[bdump] new tr.base: 0xfffff8065cb63000
[bdump]
[bdump] rip and gs don't match kernel/user, swapping...
[bdump] rip: 0x68d2aec2
[bdump] new gs.base: 0xa8d000
[bdump] new kernel_gs_base: 0xfffff8065476d000
[bdump]
[bdump] non-zero IRQL in usermode, resetting to zero...
[bdump] saving mem, get a coffee or have a smoke, this will probably take around 10-15 minutes...
[bdump] Creating C:\Users\user\Downloads\dump\mem.dmp - Active kernel and user memory range dump
[bdump] Collecting pages to write to the dump. This may take a while.
[bdump] 0% written.
[bdump] 5% written. 1 min 18 sec remaining.
[bdump] 10% written. 1 min 18 sec remaining.
[bdump] 15% written. 1 min 14 sec remaining.
[bdump] 20% written. 1 min 6 sec remaining.
[bdump] 25% written. 1 min 4 sec remaining.
[bdump] 30% written. 55 sec remaining.
[bdump] 35% written. 53 sec remaining.
[bdump] 40% written. 1 min 3 sec remaining.
[bdump] 45% written. 46 sec remaining.
[bdump] 50% written. 31 sec remaining.
[bdump] 55% written. 26 sec remaining.
[bdump] 60% written. 22 sec remaining.
[bdump] 65% written. 20 sec remaining.
[bdump] 70% written. 17 sec remaining.
[bdump] 75% written. 13 sec remaining.
[bdump] 80% written. 15 sec remaining.
[bdump] 85% written. 12 sec remaining.
[bdump] 90% written. 8 sec remaining.
[bdump] 95% written. 4 sec remaining.
[bdump] Wrote 2.4 GB in 1 min 16 sec.
[bdump] The average transfer rate was 32.3 MB/s.
[bdump] Dump successfully written
[bdump] done!
@$bdump("C:\\Users\\user\\Downloads\\dump")

[donghyunlee00]

When I opened mem.dmp with WinDbg Preview, the eip in Disassembly view and Command view were different.

• Disassembly view: 6a3baebf
• Command view: 6a3baec2

The mem.dmp did not open with WinDbg (x86) and an error occurred.

[0vercl0k]

Hey @donghyunlee00,

Thank you for taking the time to file an issue w/ a detailed report, I am able to reproduce the issue 🙏🏽

It's the first time I see this and seems pretty odd at first sight but will investigate and report back when I find anything!

Cheers

[0vercl0k]

Okay so I spent some time to investigate this, and it seems like the DumpType field has the value 0x9 which is a value that I don't know about.

The first part of the problem is that the debugger you used to take the crash-dump and the one you're using to open the dump are different; and it seems like the debugger you used to take the crash-dump is generating this new (?) type of dump which means the other one doesn't know how to read it. You can solve this problem by copying the dbgcore / dbgeng DLLs from WindbgX into the folder of the wtf binary and you should not run into the OpenDumpFile issue.

The more annoying issue though is that kdmp-parser doesn't know how to parse this crash-dump so is unable to populate the memory state, etc. I guess I'll need to investigate what this type of dump is... 😔

If you want to be unblocked, try to generate your crash-dump with the regular Windbg or an older WindbgX version, this should let you proceed.

Let me know if that makes sense!

Cheers

[ch4rli3kop]

I also had the same issue. In my case, I use !bdump_full and solve that problem.

[0vercl0k]

Thanks for sharing that @ch4rli3kop !

Cheers

[donghyunlee00]

I was late to check because of a week's trip to Venezia.

I just generated a dump with WinDbg (X64) instead of WinDbg Preview and the problem seems to have been solved.

Thanks!

[0vercl0k]

@donghyunlee00 just wanted to let you know that wtf should now handle that kind of dump file - support was added in kdmp-parser.

You probably didn't keep this dump around.. but you have; please give a shot to https://github.com/0vercl0k/wtf/releases/tag/v0.5.1 :)

If you are planning to do some fuzzing, please try out a dump acquired with WinDbg Preview and let me know :)

Cheers