.dump /f truncates complete kernel dump

[wc2023]

I'm not sure why I'm getting such a result. I'm trying to create a complete kernel dump from a live system.

Here's the steps to repro:

• I break into the Win10 kernel with WinDbgX (downloaded from the Windows Store).
• I then run:

0: kd> .dump /f c:\path-to\comp_64.dmp
Creating c:\path-to\comp_64.dmp - Full memory range dump
0% written.
Wrote 101.9 MB in 16 sec.
The average transfer rate was 6.4 MB/s.
Dump successfully written

• Then if I try to open the created .dmp file, I'm getting (also from WinDbg):

Loading Dump File [c:\path-to\comp_64.dmp]
Kernel Complete Dump File: Full address space is available

************************************************************
WARNING: Dump file has been truncated.  Data may be missing.
************************************************************

and a bunch of errors and warnings after that.

Why is it truncating it?

PS. I noticed that if I try to repeat this a few more times, the size of the resulting .dmp file that is saved is different by multiples of KB.

[Scott_Noone_OSR]

What KD protocol are you using?

[wc2023]

I'm using KDNET
I'm using KDNET

[Scott_Noone_OSR]

Are you seeing it across different systems and different NICs?

I do this regularly with kdnet and HyperV without an issue, though that's a bit of a specialized path.

[wc2023]

No. Just one. I'm using it with a VMWare Workstation 15 VM and a Win10 guest.

I can see that MSFT changed the way they collect these dumps. Now the .dump /f collects something called a "range dump", which is a new dump type vs old "full dump" type. I wonder if that has something to do with it?

[Scott_Noone_OSR]

Possible...Are you running the latest WinDbg? The alternative might be that you need to downgrade to a version that matches your Win10 target.

[wc2023]

WinDbgX always auto-updates to the latest version. It also updates the dbg engine. As for the target, I don't think the target OS matters for the dump collection - doesn't it.