Page error 0xfffffffffff8 in layer primary2 (Page Fault at entry 0xc30063 in table page table)

[jackdyson1399]

Running Volatility3 through RAM Capture from a Windows10 19041 VM the above error is returned. Attempted on volatility2 but the address space for that version of windows cannot be found and produces failed results too.
I have tried this on five different RAM Captures taken from the same system with different RAM capture software, so doubt it to be a capture issue as error persists with all dumps:

• DumpIT
• Belkasoft RAM Capture
• Magnet RAM Capturer (both full and segmented)
• FTK Imager

[atcuno]

1. What is the VM software that you are using? If its VMware fusion or Workstation, can you suspend the VM and then run the resulting *.vmem through Volatility 2 and 3? If you move or rename the *.vmem, then need to do the same steps for the associated *.vmss or analysis will not work. None of those capture tools you listed are stable or recommended by our team. Captures through the VM facilities are though, particularly VMWare.

2. Can you put the full Volatility 2 command line input/output, and also verify that you are using the latest Volatility 2 version from source?

[ikelos]

Failing all that, we can get more useful debugging information if you re-run the command but with vol.py -vvv rather than just vol.py. It does look as though it's finding/creating the appropriate symbols which should point to the process list at the right place, but 0xc30063 seems like an odd (non-aligned) offset to be reading a page entry from, which suggests the page table automagic has detected the wrong DTB value. The debugging information will tell us more...

[jackdyson1399]

Thank you for the comments.
I am using:

• VMware Workstation 15.5 Pro
• volatility (cloned from Git Index 703b29b)
• volatility3 (cloned from Git Index: 0d40753)

I have tried today using the .vmem file as you suggested (I included the .vmss file on the USB in the same directory that volatility is directed to as you mentioned). The issue is that I am trying to test RAM Capture tools that can be used for live scene forensics. So copying the .vmem file would rarely be an option.
The standard outputs for imageinfo command and the pslist command are shown below for the .vmem file, the DumpIT capture and the Belkasoft Capture, let me know if you need the full debugged (-vvv) outputs as they're extremely long and I felt this reply was already huge!

Volatility:
ImageInfo:

pslist (with Win10x64_18362 Profile):

Interestingly, pslist worked fine on the DumpIT capture, but some other plugins (i.e. consoles , hashdump ) failed.

Volatility3:
windows.info:

windows.pslist:
.vmem worked successfully (other plugins failed)

DumpIT started okay but failed at end due to Page error

...

Belkasoft started okay but failed at end due to Swap error

...

(The Magnet RAM Capture and ftk Imager captures returned the same results as Belkasoft on all tests)

p.s. sorry for the long post

[atcuno]

Thank you for all the info! This is really useful! Would it be possible to put the full pslist input/output from the following into text files:

1. dumpit and vol2
2. belkasoft and vol2
3. dumpit and vol3
4. belkasoft and vol3

I would like to see how many processes volatility 3 recovers vs volatlity 2 before volatility 3 bails out. You can attach the text files here.

[jackdyson1399]

Here are the requested files:

1. dumpITvol2.txt
2. belkvol2.txt
3. dumpITvol3.txt
4. belkvol3.txt

Also for your interest here are the cmd outputs I received:
Vol2

Vol3

[jackdyson1399]

Hello,
Is there any update on this please?

I have been continuing to try to get this working, in doing so I have tested some older versions of Windows 10 (1703 [15063 OS build] and 1909 [18363 OS build]. Both these VMs have had their RAM captured with the latest versions DumpIT and Belkasoft and saw the exact same issues as previously mentioned on the 2004 [19041].

I was wanting to know whether it is a Volatility Issue, a RAM Capture Tool Issue or a VMware Issue?

Also, are there any RAM Capture tools that you would recommend, as I know you previously mentioned that you do not support the four tools I am trying?

[atcuno]

I think we are close to diagnosing it. Can you please send the dumpit volatility 3 output with the full -vvv set ? Volatility 2 and 3 seem to be getting the same number of processes, but then Volatility 3 errors out at the end. The -vvv should tell us exactly where this is happening. Also, if output appears on the terimnal, and not in your redirected file, can you please send the full terminal prints as well?

[jackdyson1399]

Here's the output to the following command with -vvv (the errors only appeared in the terminal so I've included that first):
python vol.py -f Z:\sharedCaptures\dumpPro071020.dmp -vvv windows.pslist > C:\Users\Admin\Desktop\dumpITvvv.txt

dumpITvvv.txt

[jackdyson1399]

For your interest here is a list of the commands I've tried in dumpIT and Belkasoft and their outcome.
I tried magnet and direct vmem analysis of the same machines and they had same results as Belkasoft.

The issues seem to be with reading the registry files for the cachedump, hashdump and lsadump.
Volatility3 Testing Log.xlsx