viewer9 documentation | Index Home |
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
Posted 4 Jul 2022 last updated 22 Nov 2022 As viewer9 is just starting out, discussion is invited via email. Please send questions and comments to forum@viewer9.com directly. Threads that might be valuable to other users will be posted as part of the documentation. Posted messages will not include your address or your full name, and might be shortened for brevity.
Copyright 2022, bryantlite, Inc.