Procmon Bug: CreateFileMapping PageProtection

Procmon displays wrong PageProtection values in CreateFileMapping events for 64-bit captures. This is not a bug in the PML data, only in the way Procmon displays it. In viewer9 it is called PageProt, and is based on the integer starting at evdata[20] (see PML Binary Data and Results Offsets). Here are the flag values corresponding to the Microsoft docs for Memory Protection Constants:

0x400, "PAGE_WRITECOMBINE", 0x200, "PAGE_NOCACHE", 0x100, "PAGE_GUARD", 0x80, "PAGE_EXECUTE_WRITECOPY", 0x40, "PAGE_EXECUTE_READWRITE", 0x20, "PAGE_EXECUTE_READ", 0x10, "PAGE_EXECUTE", 0x8, "PAGE_WRITECOPY", 0x4, "PAGE_READWRITE", 0x2, "PAGE_READONLY", 0x1, "PAGE_NOACCESS",

But those only consistently match what Procmon displays for 32-bit captures. We don't know how Procmon is getting the value it displays in 64-bit captures but it seems to be a bug. viewer9 just uses the integer at evdata[20] for both 32 and 64-bit captures.

For example, in this event evdata[20] is 0x10 and viewer9 displays PAGE_EXECUTE:

But for the same event, Procmon shows "PageProtection: PAGE_EXECUTE_READWRITE|PAGE_NOCACHE":

See also

• CreateFileMapping PML Operation
• PML Binary Data and Results Offsets
• Procmon Bug: Garbage after \Device\HarddiskVolume path
• Procmon Bug: Garbage in Registry Data
• Procmon Bug: QueryDirectory Missing Filename
• Procmon Bug: QueryStreamInformationFile Alternate Data Stream
• Procmon Bug: RegQueryKey QueryKeyType Name
• Procmon Bug: RegRestoreKey/RegSaveKey Path and HivePath