Velocidex / WinPmem

The multi-platform memory acquisition tool.
Apache License 2.0
695 stars 102 forks source link

Failures to dump (winpmem 4.0 rc2) related to pagefile size. #37

Open WarrenArthur opened 3 years ago

WarrenArthur commented 3 years ago

Greetings,

Report RE: WinPmem 4.0 RC (x64)

Summary:

When the pagefile on an Azure virtual machine, located on the secondary disk) is larger than 4GB, winpmem fails to dump. When it is <= 4GB, the dump works as expected. The winpmem command is a regular dump, no additional arguments are presented to it. This behavior is consistent.

The output on the console is as follows: WinPmem64 Extracting driver to C:\Users\tadmin\AppData\Local\Temp\pmeB59A.tmp Driver Unloaded. Deleting C:\Users\tadmin\AppData\Local\Temp\pmeB59A.tmp Driver Unloaded. The produced dump-file is present, but completely empty. Is it possible to either fix this issue, or have winpmem at least output some more informative errors ?

Attachments:

WinDbg "Timeless Debugger" traces of two failures on the same machine. Traces.zip

Machine details:

Installed Physical Memory (RAM) 4,00 GB Total Physical Memory 4,00 GB Available Physical Memory 1,96 GB Total Virtual Memory 10,0 GB Available Virtual Memory 7,53 GB Page File Space 6,00 GB Page File D:\pagefile.sys Kernel DMA Protection Off Virtualization-based security Not enabled Hardware Abstraction Layer Version = "10.0.19041.964" PCR7 Configuration Binding Not Possible BaseBoard Version 7.0 BaseBoard Product Virtual Machine BaseBoard Manufacturer Microsoft Corporation BIOS Mode Legacy SMBIOS Version 2.3 BIOS Version/Date American Megatrends Inc. 090008, 7.12.2018 Processor Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz, 2594 Mhz, 2 Core(s), 2 Logical Processor(s) System Type x64-based PC System Manufacturer Microsoft Corporation System Model Virtual Machine System Name win10-21h1 OS Name Microsoft Windows 10 Pro Version 10.0.19043 Build 19043 Experience Windows Feature Experience Pack 120.2212.2020.0

Memory Details:

Resource Device Status 0x0000-0x9FFFF System board OK 0xFFFC0000-0xFFFFFFFF System board OK 0xFEC00000-0xFEC00FFF Motherboard resources OK 0xFEE00000-0xFEE00FFF Motherboard resources OK 0xFF800000-0xFFFFFFFF Microsoft Hyper-V Video OK 0xE0000000-0xFFFFFFFF PCI Bus OK 0xF8000000-0xFBFFFFFF Microsoft Hyper-V S3 Cap OK 0xA0000-0xBFFFF PCI Bus OK 0xC0000-0xDFFFF System board OK 0xE0000-0xFFFFF System board OK 0x100000-0x3FFFFFFF System board OK 0x40000000-0xFFFBFFFF PCI Bus OK

sigillaria commented 2 years ago

Sorry, I didn't look much into this, first because I don't have azure machines (no reproduction possible), second because the Windbg dumpfiles in the traces.zip are actually null byte filesize (why provide null-size windbg dump files?), and third because the dependence on pagefile size seems so weird. Winpmem doesn't depend on the hdd pagefile.sys file.

There is not much to tell from a null-sized windbg dmp file. The windbg auxiliary log files don't contain anything unusal, no exceptions (except user-induced int3 break-exceptions). But it was made with the usermode windbg, I fear it would have been of no help even if it was not null size shaped. ;-)

There is an irregularity with the RAM. "Installed Physical Memory" is recognized as 4,00 GB, "Total Physical Memory" is 4,00 GB, then expected: "Available Physical Memory" 3,96 GB. Instead, it is given as "1,96 GB". I'm not familiar with azure machines. However, I would expect around 3,96 GB addressable RAM. What is eating half of the RAM?

Microsoft states that the maximum pagefile size is allowed to be 3x the amount of physical RAM the OS has available. (I'm pretty sure it means 'avaiable physical RAM' for this calculation.) https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size With merely 1,96 GB addressable physical RAM at hand, the pagefile must not be made larger than 5.88 GB if the documention is true. Larger pagefiles will probably lead to strange phenomenons.

The winpmem dumpfile worked when the pagefile was 4 GB? When it was larger, it didn't anymore? How much larger? I daresay it's not a Winpmem issue. I suspect it might be related to the RAM irregularity. My suggestion: resolve the potential issue with the RAM (Why does Windows think it can address only 1.96 GB?), this might perhaps also solve the problem.