Failures to dump (winpmem 4.0 rc2) related to pagefile size.
Opened this issue · 1 comments
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
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.