Why volatility find me only one process

[mydockergit]

I got a memory file, I checked its profile with imageinfo:

root@kali:~/Desktop# volatility -f desktop.raw imageinfo
Volatility Foundation Volatility Framework 2.6
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x64_17134, Win10x64_14393, Win10x64_10586, Win10x64_16299, Win2016x64_14393, Win10x64_15063 (Instantiated with Win10x64_15063)
                     AS Layer1 : SkipDuplicatesAMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/root/Desktop/desktop.raw)
                      PAE type : No PAE
                           DTB : 0x1aa000L
                          KDBG : 0xf800b87544f0L
          Number of Processors : 1
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0xfffff800b76bd000L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2019-02-12 19:19:48 UTC+0000
     Image local date and time : 2019-02-12 11:19:48 -0800

Then I used Win10x64_15063 profile and when I run pslist I get:

root@kali:~/Desktop# volatility -f desktop.raw --profile=Win10x64_15063 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xffffc88a0ba11111                      786532 39...9      0 -------- ------      0    

I tried to download the file but it wrote me that the PEB is 0x0:

root@kali:~/Desktop# volatility -f desktop.raw --profile=Win10x64_15063 procdump -p 786532 -D .
Volatility Foundation Volatility Framework 2.6
Process(V)         ImageBase          Name                 Result
------------------ ------------------ -------------------- ------
0xffffc88a0ba11111 ------------------                      Error: PEB at 0x0 is unavailable (possibly due to paging)
root@kali:~/Desktop# 

Any idea what is the problem?
I tried to list all the processes with psscan but it failed:

root@kali:~/Desktop# volatility -f desktop.raw --profile=Win10x64_15063 psscan
Volatility Foundation Volatility Framework 2.6
Offset(P)          Name                PID   PPID PDB                Time created                   Time exited                   
------------------ ---------------- ------ ------ ------------------ ------------------------------ ------------------------------
WARNING : volatility.debug    : Cannot find nt!ObGetObjectType
WARNING : volatility.debug    : Cannot find nt!ObGetObjectType
Traceback (most recent call last):
  File "/usr/bin/volatility", line 192, in <module>
    main()
  File "/usr/bin/volatility", line 183, in main
    command.execute()
  File "/usr/lib/python2.7/dist-packages/volatility/commands.py", line 147, in execute
    func(outfd, data)
  File "/usr/lib/python2.7/dist-packages/volatility/plugins/filescan.py", line 428, in render_text
    for eprocess in data:
  File "/usr/lib/python2.7/dist-packages/volatility/poolscan.py", line 252, in scan
    skip_type_check = skip_type_check)
  File "/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/windows.py", line 1250, in get_object
    return self.get_object_top_down(struct_name, object_type, skip_type_check)
  File "/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/windows.py", line 1223, in get_object_top_down
    header.get_object_type() == object_type):
  File "/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/win7.py", line 155, in get_object_type
    return self.type_map.get(int(self.TypeIndex), '')
  File "/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/win10.py", line 312, in TypeIndex
    return ((addr >> 8) ^ cook ^ indx) & 0xFF
TypeError: unsupported operand type(s) for ^: 'int' and 'NoneType'

This error is related to #436 and although I tried the suggested fix, it still didn't work for me.

[mydockergit]

I am closing this case because similar case #741 was already open

[Westbrookadmin]

I am closing this case because similar case #741 was already open

Hello brother, I also encountered this problem. This problem has been bothering me for a long time. Have you solved it? Can you provide me with some help? Many thanks!