Interpreting Procmon Captured Operations and Underlying Mechanisms

Article Overview and Navigation

1. Introduction

1.1. Overview of Procmon

Process Monitor (Procmon), a cornerstone utility from the Sysinternals suite, provides unparalleled real-time observation capabilities for file system, registry, process and thread, and network activities within the Microsoft Windows operating system. It represents an amalgamation and significant enhancement of legacy Sysinternals tools, namely Filemon (for file system monitoring) and Regmon (for registry monitoring), extending their features with a rich, non-destructive filtering mechanism, comprehensive event properties including session IDs and user names, reliable process information, and full thread stacks with integrated symbol support. This document delves into its advanced application for profound system analysis, targeting users who seek to understand the intricacies of its data capture.

1.2. Purpose of this Document

This article is intended as a definitive technical reference for advanced practitioners. Its primary objective is to deliver an exhaustive analysis of the operations that Process Monitor is capable of capturing. A significant emphasis is placed on detailing the precise actions performed on Windows kernel objects and their associated system data structures. Furthermore, this document elucidates the underlying NT Native APIs, kernel mechanisms (such as I/O Request Packets - IRPs, and callbacks), and the specific Windows components involved in these operations.

2. Key Table: Procmon Captured Operations

2.1. Table Structure Explanation

To ensure clarity and facilitate in-depth understanding, the table is structured with the following columns for each captured operation:

  • Operation Class: This column denotes the broad category to which the operation belongs (e.g., File System, Registry, Process and Thread, Network Activity, Profiling Events). This classification aligns with how Procmon typically groups events and allows for a more organized approach to analysis.
  • Operation Name: This column lists the precise name of the operation as it is commonly displayed by Process Monitor in its event listing (e.g., CreateFile, RegOpenKey, Process Create, TCP Connect).
  • Specific Action(s), Target Object, and System-Level Effect: This is the most critical column, demanding and providing extreme detail. For each operation, it offers a granular breakdown of:
    • The specific actions the operation can perform. If an operation serves multiple purposes (e.g., CreateFile can open, create, query attributes, etc.), these distinct sub-actions are enumerated.
    • The primary type of Windows kernel object (e.g., FILE_OBJECT, KEY_OBJECT, EPROCESS, ETHREAD, DEVICE_OBJECT, SECTION_OBJECT, TOKEN_OBJECT, Named Pipe, Mailslot) or logical entity being acted upon is clearly identified.
    • The specific kernel-level data structures, attributes, or system states that are typically read, created, queried, or modified are detailed. Examples include Access Control Lists (ACLs) within Security Descriptors, file allocation information (e.g., in the Master File Table - MFT for NTFS), stream data (default $DATA stream, Alternate Data Streams - ADS), registry value data within hive cells, process token attributes, Object Manager namespace entries, and fields within the Process Environment Block (PEB) or Thread Environment Block (TEB).
    • It explicitly states if the operation is commonly used for critical system interactions such as:
      • Modifying permissions (e.g., changing a Discretionary Access Control List - DACL or System Access Control List - SACL).
      • Creating, reading, writing, or deleting Alternate Data Streams (ADS).
      • Querying specific file or registry key attributes or metadata without requiring full access to the object's data.
      • Opening or creating device objects or their control interfaces (e.g., for IOCTL operations).
      • Interacting with synchronization objects (though direct observation of synchronization primitives is often limited in Procmon, related operations might be captured).
  • Key Parameters Captured: This column lists notable parameters that Procmon logs for the operation, providing context for the event. Examples include Path, Desired Access, Disposition, Options, Result, Key Name, Value Name, Data, Image Path, Command Line, Destination Address, and Port. These parameters are crucial for filtering and understanding the specifics of each event.
  • Underlying Windows API/Kernel Mechanism: This column specifies the primary NT Native API function(s) (e.g., NtCreateFile, NtOpenKeyEx, NtQuerySystemInformation), I/O Request Packet (IRP) Major/Minor Function codes (e.g., IRP_MJ_CREATE, IRP_MJ_READ, IRP_MN_QUERY_DIRECTORY), kernel callback routine context (e.g., CmRegistryCallback with a specific REG_NOTIFY_CLASS value), or Event Tracing for Windows (ETW) event provider that enables Procmon to intercept and log the operation.
  • Device Destination/Component: This column identifies the primary Windows component, subsystem, or driver stack that is ultimately responsible for handling the operation or is the target of the operation. Examples include the File System Driver Stack (e.g., NTFS.SYS or FASTFAT.SYS, often via the Filter Manager FltMgr.sys), the Configuration Manager (for registry operations), the Process Manager (kernel component ntoskrnl.exe), the Object Manager (ntoskrnl.exe), or the TCP/IP Driver Stack (e.g., afd.sys, tcpip.sys, often via Winsock ETW or Windows Filtering Platform - WFP).

List of Captured Operations (Quick Navigation)

2.2. Key Table: Procmon Captured Operations
Operation Class Operation Name Specific Action(s), Target Object, and System-Level Effect Key Parameters Captured Underlying Windows API/Kernel Mechanism Device Destination/Component
File System CreateFile
  • Action: Open existing file.
    Target Object: FILE_OBJECT (representing a file).
    System-Level Effect: The I/O Manager, in conjunction with the relevant File System Driver (FSD), resolves the path. It performs access checks against the file's Security Descriptor (DACL/SACL) based on DesiredAccess flags (e.g., GENERIC_READ, FILE_READ_ATTRIBUTES). If successful, a FILE_OBJECT kernel structure is created and a handle returned. This FILE_OBJECT stores context, including FsContext (FSD-specific, e.g., File Control Block - FCB, Stream Control Block - SCB), FsContext2, DeviceObject (pointing to the volume device object), Vpb (Volume Parameter Block), SectionObjectPointer (for Cache Manager interaction), and Flags (e.g., FO_SYNCHRONOUS_IO, FO_NO_INTERMEDIATE_BUFFERING, FO_WRITE_THROUGH derived from CreateOptions in NtCreateFile ). The CurrentByteOffset within the FILE_OBJECT is initialized to zero. File system metadata like Last Access Time in the MFT (NTFS) or directory entry (FAT) may be updated. Commonly used for subsequent ReadFile, QueryInformationFile operations. The IoStatusBlock->Information field is set to FILE_OPENED.
  • Action: Open existing directory.
    Target Object: FILE_OBJECT (representing a directory). CreateOptions often includes FILE_DIRECTORY_FILE.
    System-Level Effect: Similar to opening a file, but the FILE_OBJECT represents a directory. Access checks use rights like FILE_LIST_DIRECTORY. The FsContext in the FILE_OBJECT points to directory-specific FSD structures. Commonly used as a prerequisite for QueryDirectory or NotifyChangeDirectory. IoStatusBlock->Information is FILE_OPENED.
  • Action: Create new file.
    Target Object: FILE_OBJECT (representing a new file). CreateDisposition is typically FILE_CREATE, FILE_OVERWRITE_IF, or FILE_SUPERSEDE.
    System-Level Effect: The FSD allocates necessary on-disk structures (e.g., new MFT entry in NTFS, directory entry in FAT). Initial file attributes (e.g., FILE_ATTRIBUTE_ARCHIVE, timestamps like CreationTime, LastWriteTime, LastAccessTime, ChangeTime) are set based on system defaults or FileAttributes parameter. AllocationSize parameter of NtCreateFile can specify initial disk space reservation. A default Security Descriptor is typically inherited from the parent directory or explicitly provided via ObjectAttributes->SecurityDescriptor. A FILE_OBJECT is created and populated. IoStatusBlock->Information is set to FILE_CREATED, FILE_OVERWRITTEN, or FILE_SUPERSEDED.
  • Action: Create new directory.
    Target Object: FILE_OBJECT (representing a new directory). CreateOptions includes FILE_DIRECTORY_FILE, and CreateDisposition is typically FILE_CREATE or FILE_OPEN_IF.
    System-Level Effect: Similar to creating a file, but the FSD allocates and initializes structures for an empty directory (e.g., MFT entry marked as directory, empty index allocation for NTFS). IoStatusBlock->Information is FILE_CREATED.
  • Action: Open/Create named pipe.
    Target Object: Named Pipe Object (a specialized FILE_OBJECT managed by the Named Pipe File System - NPFS, npfs.sys). Path is typically \Device\NamedPipe\<pipename>.
    System-Level Effect: Interacts with npfs.sys. For creation (server side), CreateNamedPipe() Win32 API ultimately calls NtCreateFile. For opening (client side), CreateFile() Win32 API is used. Establishes either the client or server end of the pipe. NPFS manages internal data structures for pipe instances, buffering modes (byte vs. message), read modes, and connection state. Security Descriptors can control access to the pipe.
  • Action: Open/Create mailslot.
    Target Object: Mailslot Object (a specialized FILE_OBJECT managed by the Mailslot File System - MSFS, msfs.sys). Path is typically \Device\Mailslot\<mailslotname>.
    System-Level Effect: Interacts with msfs.sys. CreateMailslot() Win32 API calls NtCreateFile. MSFS manages internal structures for message queuing and broadcast capabilities.
  • Action: Open device.
    Target Object: DEVICE_OBJECT (representing a physical or logical device, or a control interface to a driver). Path can be \Device\<DeviceName>, \\.\GlobalRoot\Device\<DeviceName>, a symbolic link like \\.\C:, or a device interface GUID path.
    System-Level Effect: The I/O Manager routes the IRP_MJ_CREATE request to the target device driver stack. The driver's DispatchCreate routine handles the request, potentially allocating driver-specific resources, performing access validation beyond standard ACLs, and preparing the device for subsequent operations. Often a prerequisite for DeviceIoControl or FileSystemControl operations. The FILE_OBJECT's FsContext and FsContext2 may be used by the driver for its own context.
  • Action: Query file/directory attributes or existence (without full open).
    Target Object: File/Directory path (a FILE_OBJECT is created internally but a handle may not be returned to the caller if the intent is purely query and no persistent handle is needed, or if CreateDisposition leads to failure like FILE_DOES_NOT_EXIST for FILE_OPEN).
    System-Level Effect: Achieved by specific DesiredAccess flags (e.g., FILE_READ_ATTRIBUTES, SYNCHRONIZE) and CreateOptions (e.g., FILE_OPEN_FOR_BACKUP_INTENT can bypass some access checks). The FSD reads metadata (e.g., from MFT for NTFS) without necessarily granting data read/write access. Checks object existence based on CreateDisposition (e.g., FILE_OPEN fails if not found, FILE_OPEN_IF creates if not found). IoStatusBlock->Information can be FILE_EXISTS or FILE_DOES_NOT_EXIST. No persistent change to file system state if only querying.
  • Action: Create/Access Alternate Data Stream (ADS).
    Target Object: FILE_OBJECT (representing a specific data stream of a file, not the default unnamed $DATA stream). The path includes the stream name syntax: filename.txt:streamname or filename.txt:streamname:$DATA.
    System-Level Effect: NTFS (and other FSDs supporting streams) parses the stream name from the path. Accesses or creates the specified named stream. An ADS is a distinct fork of data associated with a file, stored separately from the primary data stream. MFT attributes for the file are updated to reflect the existence and properties of the ADS (e.g., $ATTRIBUTE_LIST if streams cause attributes to exceed base MFT record, or a separate MFT record for very large ADS). Commonly used for storing metadata, Zone.Identifier, or covertly storing data.
  • Action: Open for Deletion (Mark for delete on close).
    Target Object: FILE_OBJECT. CreateOptions includes FILE_DELETE_ON_CLOSE.
    System-Level Effect: The I/O Manager sets the FO_DELETE_ON_CLOSE flag in the FILE_OBJECT's Flags field. The file is not deleted immediately. Deletion occurs when the last handle to this specific FILE_OBJECT instance is closed (via NtClose, leading to IRP_MJ_CLEANUP and then IRP_MJ_CLOSE). Other open handles to the same underlying file (via different FILE_OBJECTs) do not prevent deletion once this FO_DELETE_ON_CLOSE marked handle is closed. This is distinct from SetDispositionInformationFile which marks the underlying file system object for deletion upon closure of any handle.
Path, Result, Desired Access, Disposition, Options, ShareMode, AllocationSize, FileAttributes, Impersonation, Security QOS, EaBuffer. NtCreateFile / ZwCreateFile. This generates an IRP_MJ_CREATE. Parameters.Create.Options in the IRP contains CreateDisposition (high 8 bits) and CreateOptions (low 24 bits). Parameters.Create.SecurityContext->DesiredAccess holds access flags. Parameters.Create.ShareAccess holds sharing flags. I/O Manager, File System Driver Stack (e.g., NTFS.SYS, FASTFAT.SYS via FltMgr.sys ), NPFS (npfs.sys) for named pipes, MSFS (msfs.sys) for mailslots, or specific Device Driver.
File System CloseFile
  • Action: Close an open handle to a file, directory, device, named pipe, or mailslot.
    Target Object: FILE_OBJECT.
    System-Level Effect: NtClose decrements the handle count for the specified FILE_OBJECT within the calling process's handle table. If this is the last handle to this FILE_OBJECT in the process, the Object Manager initiates cleanup. An IRP_MJ_CLEANUP is sent to the driver stack. This allows drivers to cancel any pending IRPs associated with this FILE_OBJECT and release per-handle resources. After IRP_MJ_CLEANUP completes for all handles to the FILE_OBJECT across all processes, if the FILE_OBJECT's reference count (maintained by the Object Manager, distinct from handle count) drops to zero (meaning no other kernel components like Cache Manager or Memory Manager are referencing it), an IRP_MJ_CLOSE is sent. The IRP_MJ_CLOSE allows the FSD to perform final deallocation of in-memory structures (e.g., FCB, SCB, VCB if last close on volume). If the FO_DELETE_ON_CLOSE flag was set in the FILE_OBJECT (e.g., by CreateFile with FILE_FLAG_DELETE_ON_CLOSE or by SetDispositionInformationFile with DeleteFile = TRUE), the file system deletes the on-disk file/directory during IRP_MJ_CLEANUP or IRP_MJ_CLOSE processing, after ensuring no outstanding handles or references prevent deletion. For files marked with FILE_DISPOSITION_INFORMATION, deletion occurs when the link count for the file is zero and all open handles for the file object have been closed. The FILE_OBJECT itself is then deallocated.
Path, Result. NtClose / ZwClose. This initiates IRP_MJ_CLEANUP followed by IRP_MJ_CLOSE if it's the last handle/reference to the kernel object. I/O Manager, Object Manager, File System Driver Stack, or specific Device Driver.
File System ReadFile
  • Action: Read data from an open file, device, or pipe.
    Target Object: FILE_OBJECT (must have been opened with appropriate read access, e.g., FILE_READ_DATA or GENERIC_READ ).
    System-Level Effect: Data is transferred from the source into the caller-supplied buffer. If the FILE_OBJECT was opened for cached I/O (default), the Cache Manager is involved. If data is in the cache, it's copied from there. If not (cache miss), the Cache Manager reads data from the FSD (which reads from disk) into the cache, then to the user buffer. If FILE_NO_INTERMEDIATE_BUFFERING was specified during CreateFile (FO_NO_INTERMEDIATE_BUFFERING flag in FILE_OBJECT ), I/O bypasses the cache; reads must be sector-aligned and sector-sized multiples. The FILE_OBJECT's CurrentByteOffset field is updated by the number of bytes read if the ByteOffset parameter to NtReadFile is NULL or specifies FILE_USE_FILE_POINTER_POSITION. Otherwise, the read occurs at the specified ByteOffset, and CurrentByteOffset is updated. Reading beyond EOF results in an error or zero bytes read. Modifies file's Last Access Time (FSD and mount option dependent). The IoStatusBlock->Information field is set to the number of bytes actually read.
Path, Result, Offset, Length, I/O Flags (e.g., Paging I/O, Non-cached), Priority, Buffer. NtReadFile / ZwReadFile. This generates an IRP_MJ_READ. Parameters.Read.Length, Parameters.Read.ByteOffset, Parameters.Read.Key are key IRP parameters. Data transfer uses Irp->AssociatedIrp.SystemBuffer for buffered I/O or Irp->MdlAddress for direct I/O. I/O Manager, Cache Manager, File System Driver Stack (e.g., NTFS.SYS via FltMgr.sys), or specific Device Driver.
File System WriteFile
  • Action: Write data to an open file, device, or pipe.
    Target Object: FILE_OBJECT (must have been opened with appropriate write access, e.g., FILE_WRITE_DATA, FILE_APPEND_DATA, or GENERIC_WRITE ).
    System-Level Effect: Data from the caller-supplied buffer is transferred to the target. For cached I/O, data is typically written to the Cache Manager's buffers, which are later flushed to disk by the Lazy Writer or an explicit FlushBuffersFile call. If FO_WRITE_THROUGH flag is set on FILE_OBJECT (from FILE_FLAG_WRITE_THROUGH CreateOption ), data is written through the cache to persistent storage before the operation completes. If FILE_NO_INTERMEDIATE_BUFFERING was specified (FO_NO_INTERMEDIATE_BUFFERING flag ), I/O bypasses the cache; writes must be sector-aligned and sector-sized multiples. The FILE_OBJECT's CurrentByteOffset field is updated if ByteOffset to NtWriteFile is NULL or FILE_USE_FILE_POINTER_POSITION. If FILE_APPEND_DATA was the only write access granted, ByteOffset is ignored, and writes occur at current EOF. Writing past current End-Of-File (EOF) extends the file; AllocationSize, EndOfFile, and ValidDataLength in FSD structures (e.g., MFT for NTFS) and FILE_OBJECT are updated. Timestamps (LastWriteTime, ChangeTime) are updated. FILE_ATTRIBUTE_ARCHIVE is typically set. IoStatusBlock->Information is set to the number of bytes written.
Path, Result, Offset, Length, I/O Flags (e.g., Paging I/O, Non-cached, Write Through), Priority, Buffer. NtWriteFile / ZwWriteFile. This generates an IRP_MJ_WRITE. Parameters.Write.Length, Parameters.Write.ByteOffset, Parameters.Write.Key are key IRP parameters. Data transfer uses Irp->AssociatedIrp.SystemBuffer for buffered I/O or Irp->MdlAddress for direct I/O. I/O Manager, Cache Manager, File System Driver Stack (e.g., NTFS.SYS via FltMgr.sys), or specific Device Driver.
File System QueryDirectory
  • Action: Enumerate files and subdirectories within a directory.
    Target Object: FILE_OBJECT (representing an open directory, must have been opened with FILE_LIST_DIRECTORY access).
    System-Level Effect: Retrieves information about entries (files and subdirectories) within the specified directory. The type and amount of information returned for each entry are determined by the FileInformationClass parameter supplied to NtQueryDirectoryFile(Ex). Common classes include FileDirectoryInformation (basic info), FileFullDirectoryInformation (more details), FileIdBothDirectoryInformation (includes File ID), FileNamesInformation (names only). The FSD reads directory data (e.g., from MFT B*-tree index for NTFS, or directory file cluster chain for FAT) and populates the user-supplied FileInformation buffer with an array of FILE_XXX_INFORMATION structures, one for each matching entry. The FileName parameter can specify a wildcard pattern (e.g., *.txt) to filter entries. RestartScan (for NtQueryDirectoryFile) or QueryFlags (e.g., SL_RESTART_SCAN for NtQueryDirectoryFileEx) control whether the scan starts from the beginning or resumes from a previous call. Modifies the directory's Last Access Time (FSD dependent). If the buffer is too small, STATUS_BUFFER_OVERFLOW or STATUS_NO_MORE_FILES might be returned, with IoStatusBlock->Information indicating bytes written.
Path, Result, Filter (wildcard pattern), FileInformationClass, Length (of buffer). NtQueryDirectoryFile / ZwQueryDirectoryFile , NtQueryDirectoryFileEx / ZwQueryDirectoryFileEx. This generates an IRP_MJ_DIRECTORY_CONTROL with minor function IRP_MN_QUERY_DIRECTORY. Key IRP parameters include IrpSp->Parameters.QueryDirectory.Length, IrpSp->Parameters.QueryDirectory.FileName, IrpSp->Parameters.QueryDirectory.FileInformationClass, IrpSp->Parameters.QueryDirectory.FileIndex, and IrpSp->Parameters.QueryDirectory.DirectoryBuffer or MdlAddress. I/O Manager, File System Driver Stack (e.g., NTFS.SYS via FltMgr.sys).
File System QueryBasicInformationFile
  • Action: Query basic attribute information for a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves basic file attributes. The FSD reads metadata (e.g., standard information attribute from MFT for NTFS) and populates the user-supplied buffer with a FILE_BASIC_INFORMATION structure. This structure includes CreationTime, LastAccessTime, LastWriteTime, ChangeTime (all LARGE_INTEGER timestamps), and FileAttributes (ULONG, e.g., FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_DIRECTORY). Requires FILE_READ_ATTRIBUTES access. Does not typically modify file system state, but access may update Last Access Time depending on FSD behavior and mount options.
Path, Result, FileInformationClass (FileBasicInformation), Length, Buffer (receives FILE_BASIC_INFORMATION). NtQueryInformationFile / ZwQueryInformationFile. This generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileBasicInformation. I/O Manager, File System Driver Stack.
File System QueryStandardInformationFile
  • Action: Query standard information for a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves standard file information. The FSD populates the user-supplied buffer with a FILE_STANDARD_INFORMATION structure. This includes AllocationSize (actual disk space allocated), EndOfFile (logical end of file), NumberOfLinks (for hard links, NTFS specific), DeletePending (BOOLEAN), and Directory (BOOLEAN). Requires FILE_READ_ATTRIBUTES access. Reads metadata from FSD structures (e.g., MFT for NTFS).
Path, Result, FileInformationClass (FileStandardInformation), Length, Buffer (receives FILE_STANDARD_INFORMATION). NtQueryInformationFile / ZwQueryInformationFile. This generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileStandardInformation. I/O Manager, File System Driver Stack.
File System QueryNameInformationFile
  • Action: Query the name of a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves the name of the file associated with the FILE_OBJECT. The FSD populates the user-supplied buffer with a FILE_NAME_INFORMATION structure, which contains a FileNameLength (ULONG) and FileName (WCHAR array). The name returned is typically relative to the volume root or the name used to open the file, depending on how the FILE_OBJECT was created and FSD implementation. This information is often stored in the FILE_OBJECT's FileName field itself or derived by the FSD.
Path, Result, FileInformationClass (FileNameInformation), Length, Buffer (receives FILE_NAME_INFORMATION). NtQueryInformationFile / ZwQueryInformationFile. This generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileNameInformation. I/O Manager, File System Driver Stack.
File System QueryNetworkOpenInformationFile
  • Action: Query network-specific file information.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_NETWORK_OPEN_INFORMATION structure. This includes CreationTime, LastAccessTime, LastWriteTime, ChangeTime, AllocationSize, EndOfFile, and FileAttributes. This is often used by network redirectors to get a snapshot of essential file metadata efficiently for remote file access.
Path, Result, FileInformationClass (FileNetworkOpenInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileNetworkOpenInformation. I/O Manager, File System Driver Stack, Network Redirector.
File System QueryPositionInformationFile
  • Action: Query the current file pointer position.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_POSITION_INFORMATION structure, which contains the CurrentByteOffset (LARGE_INTEGER) of the FILE_OBJECT. This reflects the current position for sequential I/O operations on that handle.
Path, Result, FileInformationClass (FilePositionInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FilePositionInformation. I/O Manager.
File System QueryEAFile
  • Action: Query Extended Attributes (EAs) for a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves EA information. The FSD reads EA data, which is stored separately (e.g., in the $EA attribute in NTFS MFT record or a separate EA file for FAT). The user provides a buffer to receive FILE_FULL_EA_INFORMATION structures. EAs are less common now but were used for OS/2 compatibility and some specialized applications.
Path, Result, FileInformationClass (FileEaInformation or related), Length, Buffer. NtQueryEaFile / ZwQueryEaFile (more likely than NtQueryInformationFile for full EA query). NtQueryInformationFile with FileEaInformation retrieves a summary (FILE_EA_INFORMATION structure: EaSize). Generates IRP_MJ_QUERY_EA. I/O Manager, File System Driver Stack.
File System QueryStreamInformationFile
  • Action: Query information about named streams (Alternate Data Streams - ADS) for a file.
    Target Object: FILE_OBJECT (representing the base file).
    System-Level Effect: Retrieves a list of FILE_STREAM_INFORMATION structures, one for each named stream associated with the file. Each structure contains the StreamNameLength, StreamSize, StreamAllocationSize, and StreamName. NTFS stores stream information in MFT attributes (e.g., as separate $DATA attributes with names).
Path, Result, FileInformationClass (FileStreamInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileStreamInformation. I/O Manager, File System Driver Stack (primarily NTFS).
File System QueryAttributeTagFile
  • Action: Query file attribute and reparse tag information.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_ATTRIBUTE_TAG_INFORMATION structure, which contains FileAttributes (ULONG) and ReparseTag (ULONG). This is useful for quickly getting attributes and identifying if a file is a reparse point (e.g., symbolic link, mount point, HSM file) and its specific reparse tag type. Reads metadata from FSD structures (e.g., MFT for NTFS).
Path, Result, FileInformationClass (FileAttributeTagInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileAttributeTagInformation. I/O Manager, File System Driver Stack.
File System QueryNormalizedNameInformationFile
  • Action: Query the normalized name of a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_NAME_INFORMATION structure containing the normalized (canonical) path of the file. Normalization involves resolving case, short names (8.3), and potentially symbolic links depending on how the handle was opened.
Path, Result, FileInformationClass (FileNormalizedNameInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileNormalizedNameInformation. I/O Manager, File System Driver Stack.
File System QueryFileInternalInformationFile
  • Action: Query internal file system information for a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_INTERNAL_INFORMATION structure, which contains the IndexNumber (LARGE_INTEGER). For NTFS, this is the File ID (MFT Reference Number). This provides a unique identifier for the file on the volume.
Path, Result, FileInformationClass (FileInternalInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileInternalInformation. I/O Manager, File System Driver Stack.
File System QueryAllInformationFile
  • Action: Query a comprehensive set of information for a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_ALL_INFORMATION structure. This structure consolidates information from FILE_BASIC_INFORMATION, FILE_STANDARD_INFORMATION, FILE_INTERNAL_INFORMATION, FILE_EA_INFORMATION, FILE_POSITION_INFORMATION, and FILE_NAME_INFORMATION. It's a way to get a lot of metadata in one call.
Path, Result, FileInformationClass (FileAllInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileAllInformation. I/O Manager, File System Driver Stack.
File System SetBasicInformationFile
  • Action: Set basic attribute information for a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Modifies basic file attributes using a FILE_BASIC_INFORMATION structure. Allows setting CreationTime, LastAccessTime, LastWriteTime, ChangeTime, and FileAttributes. Requires FILE_WRITE_ATTRIBUTES access. Changes are written to FSD metadata (e.g., MFT standard information attribute for NTFS). Commonly used to change timestamps or attributes like ReadOnly, Hidden, System.
Path, Result, FileInformationClass (FileBasicInformation), Length, Buffer (contains FILE_BASIC_INFORMATION). NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FileBasicInformation. I/O Manager, File System Driver Stack.
File System SetDispositionInformationFile
  • Action: Mark a file for deletion upon handle closure.
    Target Object: FILE_OBJECT.
    System-Level Effect: Uses a FILE_DISPOSITION_INFORMATION structure. If its DeleteFile member is TRUE, the file system marks the file for deletion. The actual deletion occurs when the last open handle to the file is closed and the link count is zero. This sets the FO_DELETE_ON_CLOSE flag in the underlying file system object, not just the current FILE_OBJECT instance (contrast with CreateFile's FILE_FLAG_DELETE_ON_CLOSE). Requires DELETE access on the file. FileDispositionInformationEx provides more flags for how deletion should occur (e.g., POSIX semantics).
Path, Result, FileInformationClass (FileDispositionInformation or FileDispositionInformationEx), DeleteFile (BOOLEAN). NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FileDispositionInformation or FileDispositionInformationEx. I/O Manager, File System Driver Stack.
File System SetRenameInformationFile
  • Action: Rename a file or directory, or move it to another directory on the same volume.
    Target Object: FILE_OBJECT (representing the source file/directory).
    System-Level Effect: Uses a FILE_RENAME_INFORMATION structure, which specifies ReplaceIfExists (BOOLEAN), RootDirectory (HANDLE to target parent directory, optional), FileNameLength, and FileName (new name/path). Modifies directory entries in both source and destination parent directories. For NTFS, updates the file name attribute(s) in the MFT record and potentially $INDEX_ROOT / $INDEX_ALLOCATION attributes of directories. Requires DELETE access to the source file/directory and appropriate write access to the target parent directory. FileRenameInformationEx offers more flags.
Path, Result, FileInformationClass (FileRenameInformation or FileRenameInformationEx), ReplaceIfExists, TargetFileName. NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FileRenameInformation or FileRenameInformationEx. I/O Manager, File System Driver Stack.
File System SetEndOfFileInformationFile
  • Action: Set the end-of-file position for a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Uses a FILE_END_OF_FILE_INFORMATION structure containing the new EndOfFile (LARGE_INTEGER). Can truncate the file (data beyond new EOF is lost, deallocated) or extend it. If extended, the space between the old EOF and new EOF is typically zeroed out by the FSD (behavior can be FSD-specific). Updates EndOfFile and ValidDataLength in FILE_OBJECT and FSD structures (e.g., MFT data attribute for NTFS). Requires FILE_WRITE_DATA access.
Path, Result, FileInformationClass (FileEndOfFileInformation), EndOfFile. NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FileEndOfFileInformation. I/O Manager, File System Driver Stack.
File System SetAllocationInformationFile
  • Action: Set the allocation size for a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Uses a FILE_ALLOCATION_INFORMATION structure containing the new AllocationSize (LARGE_INTEGER). Can pre-allocate disk space for a file to improve performance for sequential writes or truncate allocated space (if new size is smaller and FSD supports it). Modifies file system allocation metadata (e.g., allocation bitmap, MFT data attribute runlists for NTFS). Requires FILE_WRITE_DATA access.
Path, Result, FileInformationClass (FileAllocationInformation), AllocationSize. NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FileAllocationInformation. I/O Manager, File System Driver Stack.
File System SetPositionInformationFile
  • Action: Set the current file pointer position.
    Target Object: FILE_OBJECT.
    System-Level Effect: Uses a FILE_POSITION_INFORMATION structure to set the CurrentByteOffset (LARGE_INTEGER) field in the FILE_OBJECT. This affects subsequent NtReadFile or NtWriteFile operations that rely on the current file pointer (i.e., when their ByteOffset parameter is NULL). Does not directly modify on-disk structures.
Path, Result, FileInformationClass (FilePositionInformation), Position. NtSetInformationFile / ZwSetInformationFile. Generates an IRP_MJ_SET_INFORMATION. Parameters.SetFile.FileInformationClass is FilePositionInformation. I/O Manager.
File System QuerySecurityFile
  • Action: Query the security descriptor of a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves the Security Descriptor (Owner, Group, DACL, SACL) associated with the file system object. The specific parts of the Security Descriptor retrieved depend on the SecurityInformation flags passed to NtQuerySecurityObject. Requires appropriate access rights on the handle (e.g., READ_CONTROL to read DACL, Owner, Group; ACCESS_SYSTEM_SECURITY to read SACL). The Security Descriptor is read from the file system's metadata storage (e.g., $SECURITY_DESCRIPTOR attribute in MFT for NTFS, or separate $SDS stream entries). The returned SECURITY_DESCRIPTOR structure is typically in self-relative format.
Path, Result, SecurityInformation, Length, Buffer (receives SECURITY_DESCRIPTOR). NtQuerySecurityObject / ZwQuerySecurityObject. This generates an IRP_MJ_QUERY_SECURITY. I/O Manager, File System Driver Stack, Security Reference Monitor.
File System SetSecurityFile
  • Action: Modify the security descriptor of a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Updates the Security Descriptor (Owner, Group, DACL, and/or SACL) associated with the file system object. The specific parts modified depend on the SecurityInformation flags passed to NtSetSecurityObject (e.g., DACL_SECURITY_INFORMATION to set DACL). Requires appropriate access rights on the handle (e.g., WRITE_DAC to modify DACL, WRITE_OWNER to modify Owner/Group, ACCESS_SYSTEM_SECURITY to modify SACL ). Changes are written to the file system's metadata storage for security descriptors. This operation directly modifies permissions on the object.
Path, Result, SecurityInformation, SecurityDescriptor. NtSetSecurityObject / ZwSetSecurityObject. This generates an IRP_MJ_SET_SECURITY. Key IRP parameters are IrpSp->Parameters.SetSecurity.SecurityInformation and IrpSp->Parameters.SetSecurity.SecurityDescriptor. I/O Manager, File System Driver Stack, Security Reference Monitor.
File System FlushBuffersFile
  • Action: Flush cached data for a file to persistent storage.
    Target Object: FILE_OBJECT.
    System-Level Effect: Ensures that any modified data for the specified file residing in the system's file cache (managed by the Cache Manager) is written to the physical storage medium. This also typically flushes file metadata associated with the data. If the FILE_OBJECT refers to a volume handle, all modified data for all files on that volume may be flushed. NtFlushBuffersFileEx provides finer control with Flags like FLUSH_FLAGS_FILE_DATA_ONLY (writes file data, no metadata, no underlying storage sync), FLUSH_FLAGS_NO_SYNC (writes file data and metadata, no underlying storage sync), or FLUSH_FLAGS_FILE_DATA_SYNC_ONLY (writes file data and necessary metadata, syncs underlying storage).
Path, Result, Flags (for Ex version). NtFlushBuffersFile / ZwFlushBuffersFile , NtFlushBuffersFileEx / ZwFlushBuffersFileEx. This generates an IRP_MJ_FLUSH_BUFFERS. I/O Manager, Cache Manager, File System Driver Stack.
File System LockFile
  • Action: Lock a byte range within a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Prevents other processes or threads from accessing the specified byte range in a manner that conflicts with the lock type (exclusive or shared). The FSD manages byte-range lock information, typically associating it with the FILE_OBJECT or FCB. If FailImmediately is TRUE in NtLockFile, the call returns immediately if the lock cannot be granted; otherwise, it may block until the lock is acquired or an error occurs. This affects how other NtReadFile, NtWriteFile, and NtLockFile operations on the same range by other openers behave. The lock is associated with the FileHandle and the ProcessId that acquired it.
Path, Result, Offset, Length, ExclusiveLock (BOOLEAN), FailImmediately (BOOLEAN), Key. NtLockFile / ZwLockFile. This generates an IRP_MJ_LOCK_CONTROL with minor function IRP_MN_LOCK. Key IRP parameters include IrpSp->Parameters.LockControl.Length, ByteOffset, Key, FailImmediately, ExclusiveLock. I/O Manager, File System Driver Stack.
File System UnlockFileSingle
  • Action: Unlock a previously locked byte range within a file.
    Target Object: FILE_OBJECT.
    System-Level Effect: Releases a previously acquired byte-range lock on the specified range. The ByteOffset and Length must exactly match a range previously locked by a single NtLockFile call on the same FileHandle by the same process. Makes the range accessible again to other processes/threads according to standard file sharing rules. The FSD updates its internal lock information.
Path, Result, Offset, Length, Key. NtUnlockFile / ZwUnlockFile. This generates an IRP_MJ_LOCK_CONTROL with minor function IRP_MN_UNLOCK_SINGLE. Key IRP parameters are IrpSp->Parameters.LockControl.Length, ByteOffset, Key. I/O Manager, File System Driver Stack.
File System DeviceIoControl
  • Action: Send a control code to a device driver.
    Target Object: FILE_OBJECT (representing an open handle to a device, or a file/directory on a volume if the IOCTL is intended for the FSD or volume driver).
    System-Level Effect: Transmits a device-specific or file-system-specific control code (IoControlCode) along with optional input and output buffers to the target device driver. The driver interprets the IoControlCode and performs the requested action. Effects vary widely depending on the IoControlCode and the driver (e.g., querying disk geometry IOCTL_DISK_GET_DRIVE_GEOMETRY, managing volumes IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, interacting with filter driver control interfaces). Buffering methods (METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, METHOD_NEITHER), encoded in the IoControlCode, determine how InputBuffer and OutputBuffer are handled by the I/O Manager (e.g., copied to/from Irp->AssociatedIrp.SystemBuffer, or MDL created at Irp->MdlAddress for direct access to user buffer).
Path, Result, IoControlCode (Control Code), InputBuffer, OutputBuffer, InputBufferLength, OutputBufferLength. NtDeviceIoControlFile / ZwDeviceIoControlFile. This generates an IRP_MJ_DEVICE_CONTROL. Key IRP parameters are IrpSp->Parameters.DeviceIoControl.IoControlCode, InputBufferLength, OutputBufferLength, and buffer pointers depending on buffering method. I/O Manager, specific Device Driver (e.g., disk driver disk.sys, volume manager volmgr.sys, partition manager partmgr.sys, custom device driver).
File System FileSystemControl
  • Action: Send a control code to a file system or file system filter driver.
    Target Object: FILE_OBJECT (representing an open handle to a file, directory, or volume).
    System-Level Effect: Transmits a file system-specific control code (FsControlCode) to the FSD or a file system filter driver. Used for operations like requesting opportunistic locks (oplocks, e.g., FSCTL_REQUEST_OPLOCK ), managing reparse points (FSCTL_SET_REPARSE_POINT, FSCTL_GET_REPARSE_POINT, FSCTL_DELETE_REPARSE_POINT), managing file/directory compression (FSCTL_SET_COMPRESSION, FSCTL_GET_COMPRESSION), or querying file system statistics (FSCTL_FILESYSTEM_GET_STATISTICS). The effect depends entirely on the FsControlCode and its implementation within the FSD or filter. Buffering methods are also determined by the FsControlCode.
Path, Result, FsControlCode (Control Code), InputBuffer, OutputBuffer, InputBufferLength, OutputBufferLength. NtFsControlFile / ZwFsControlFile. This generates an IRP_MJ_FILE_SYSTEM_CONTROL. Key IRP parameters are IrpSp->Parameters.FileSystemControl.FsControlCode (for common parameters) and buffer details. Minor function codes like IRP_MN_USER_FS_REQUEST or IRP_MN_MOUNT_VOLUME can be involved. I/O Manager, File System Driver Stack (e.g., NTFS.SYS, FltMgr.sys).
File System CreateFileMapping
  • Action: Create or open a named or unnamed file mapping object (section object) for a file.
    Target Object: SECTION_OBJECT.
    System-Level Effect: Creates a SECTION_OBJECT in kernel memory, backed by the specified FileHandle (if not INVALID_HANDLE_VALUE). This object represents a region of the file that can be mapped into a process's address space using NtMapViewOfSection. NtCreateSection parameters like MaximumSize, SectionPageProtection (e.g., PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE_READWRITE), and AllocationAttributes (e.g., SEC_COMMIT, SEC_IMAGE for executables, SEC_RESERVE) define the section's properties and how memory is committed. If MaximumSize is larger than the file and the section is writable, the file on disk may be extended. The SectionObjectPointer field in the FILE_OBJECT structure is updated by the Memory Manager to point to the section object's control area. This is fundamental for memory-mapped file I/O and for loading executable images (SEC_IMAGE). For SEC_IMAGE, the PE header is parsed, and sections are prepared for mapping.
Path (of the file being mapped), Result, Name (of the section object, if named), Protection (SectionPageProtection), MaximumSize, AllocationAttributes. NtCreateSection / ZwCreateSection , or NtCreateSectionEx / ZwCreateSectionEx. This may involve the file system via an IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION to ensure cache coherency and proper file locking before the section is created. Memory Manager, Object Manager, File System Driver Stack (for file access, cache coherency, and synchronization).
File System NotifyChangeDirectory
  • Action: Request notification when changes occur in a directory or its subtree.
    Target Object: FILE_OBJECT (representing an open directory).
    System-Level Effect: Registers an asynchronous request with the FSD to be notified of changes within the specified directory. If WatchTree is TRUE, changes in subdirectories are also monitored. The CompletionFilter parameter specifies which types of changes to monitor (e.g., FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_ATTRIBUTES, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_SECURITY, FILE_NOTIFY_CHANGE_STREAM_NAME etc. ). When a matching change occurs, the FSD completes the pending IRP_MJ_DIRECTORY_CONTROL (minor function IRP_MN_NOTIFY_CHANGE_DIRECTORY), and the provided Buffer is filled with one or more FILE_NOTIFY_INFORMATION structures detailing the changes (Action, FileName, FileNameLength, NextEntryOffset). The operation is typically pending until a change occurs or it's cancelled.
Path, Result, CompletionFilter (Watch Filter), WatchTree (BOOLEAN), Buffer, Length. NtNotifyChangeDirectoryFile / ZwNotifyChangeDirectoryFile. This generates an IRP_MJ_DIRECTORY_CONTROL with minor function IRP_MN_NOTIFY_CHANGE_DIRECTORY. Key IRP parameters are IrpSp->Parameters.NotifyDirectory.CompletionFilter and IrpSp->Parameters.NotifyDirectory.WatchTree (implicitly via ZwNotifyChangeDirectoryFile parameter). I/O Manager, File System Driver Stack.
File System QueryAllInformationFile
  • Action: Query a comprehensive set of information for a file or directory.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_ALL_INFORMATION structure. This structure aggregates information typically found in FILE_BASIC_INFORMATION (timestamps, attributes), FILE_STANDARD_INFORMATION (allocation size, EOF, links), FILE_INTERNAL_INFORMATION (file ID), FILE_EA_INFORMATION (EA size), FILE_POSITION_INFORMATION (current byte offset), and FILE_NAME_INFORMATION (file name). This provides a convenient way to obtain a wide range of metadata in a single kernel call. The FSD gathers this data from its internal structures (e.g., MFT record for NTFS).
Path, Result, FileInformationClass (FileAllInformation), Length, Buffer (receives FILE_ALL_INFORMATION). NtQueryInformationFile / ZwQueryInformationFile. This generates an IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileAllInformation. I/O Manager, File System Driver Stack.
File System QueryAttributeInformationVolume
  • Action: Query attribute information for a volume.
    Target Object: FILE_OBJECT (representing an open handle on the volume, or a file/directory on it).
    System-Level Effect: Retrieves a FILE_FS_ATTRIBUTE_INFORMATION structure. This structure contains FileSystemAttributes (flags like FILE_CASE_SENSITIVE_SEARCH, FILE_FILE_COMPRESSION), MaximumComponentNameLength (in bytes), and FileSystemNameLength / FileSystemName (e.g., "NTFS", "FAT32"). This information is queried from the FSD managing the volume.
Path (of file/dir on volume), Result, FsInformationClass (FileFsAttributeInformation), Length, Buffer. NtQueryVolumeInformationFile / ZwQueryVolumeInformationFile. Generates an IRP_MJ_QUERY_VOLUME_INFORMATION. Parameters.QueryVolume.FsInformationClass is FileFsAttributeInformation. I/O Manager, File System Driver Stack.
File System QueryFullSizeInformationVolume
  • Action: Query full size information for a volume.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_FS_FULL_SIZE_INFORMATION structure. This includes TotalAllocationUnits, CallerAvailableAllocationUnits, ActualAvailableAllocationUnits (all LARGE_INTEGER), SectorsPerAllocationUnit, and BytesPerSector. Provides detailed disk space usage and availability.
Path, Result, FsInformationClass (FileFsFullSizeInformation), Length, Buffer. NtQueryVolumeInformationFile / ZwQueryVolumeInformationFile. Generates an IRP_MJ_QUERY_VOLUME_INFORMATION. Parameters.QueryVolume.FsInformationClass is FileFsFullSizeInformation. I/O Manager, File System Driver Stack.
File System QuerySizeInformationVolume
  • Action: Query size information for a volume (caller's perspective).
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_FS_SIZE_INFORMATION structure. This includes TotalAllocationUnits, AvailableAllocationUnits (available to the caller, considering quotas), SectorsPerAllocationUnit, and BytesPerSector.
Path, Result, FsInformationClass (FileFsSizeInformation), Length, Buffer. NtQueryVolumeInformationFile / ZwQueryVolumeInformationFile. Generates an IRP_MJ_QUERY_VOLUME_INFORMATION. Parameters.QueryVolume.FsInformationClass is FileFsSizeInformation. I/O Manager, File System Driver Stack.
File System QueryObjectIdInformationVolume
  • Action: Query Object ID information for a volume.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_FS_OBJECTID_INFORMATION structure. This contains the ObjectId (GUID) of the volume (if supported by the file system, e.g., NTFS) and ExtendedInfo (48 bytes of FSD-specific data). This is different from the unique volume name (e.g., \\?\Volume{guid}\).
Path, Result, FsInformationClass (FileFsObjectIdInformation), Length, Buffer. NtQueryVolumeInformationFile / ZwQueryVolumeInformationFile. Generates an IRP_MJ_QUERY_VOLUME_INFORMATION. Parameters.QueryVolume.FsInformationClass is FileFsObjectIdInformation. I/O Manager, File System Driver Stack.
File System QueryDeviceInformationVolume
  • Action: Query device information for a volume.
    Target Object: FILE_OBJECT.
    System-Level Effect: Retrieves a FILE_FS_DEVICE_INFORMATION structure. This includes DeviceType (e.g., FILE_DEVICE_DISK, FILE_DEVICE_CD_ROM) and Characteristics (e.g., FILE_REMOVABLE_MEDIA, FILE_READ_ONLY_DEVICE). If FileHandle represents a direct device open, only FileFsDeviceInformation can be specified as FsInformationClass.
Path, Result, FsInformationClass (FileFsDeviceInformation), Length, Buffer. NtQueryVolumeInformationFile / ZwQueryVolumeInformationFile. Generates an IRP_MJ_QUERY_VOLUME_INFORMATION. Parameters.QueryVolume.FsInformationClass is FileFsDeviceInformation. I/O Manager, File System Driver Stack, underlying Storage Driver.
File System QueryOpen
  • Action: This is not a distinct operation but rather the CreateFile operation itself, often filtered in Procmon to show only successful opens or attempts to open that don't result in creation. The "Result" column in Procmon for a CreateFile operation will indicate SUCCESS if an open was successful, and the "Disposition" detail will show values like Open, OpenIf.
    Target Object: FILE_OBJECT.
    System-Level Effect: As per CreateFile action "Open existing file/directory". Path resolution, access checks, FILE_OBJECT creation and population. The key outcome is obtaining a handle to an existing file system object.
Path, Result, Desired Access, Disposition, Options. NtCreateFile / ZwCreateFile. IRP_MJ_CREATE. I/O Manager, File System Driver Stack.
File System QueryRemoteProtocolInformation
  • Action: Query remote protocol information for a file handle.
    Target Object: FILE_OBJECT (representing a file opened via a network redirector).
    System-Level Effect: Retrieves a FILE_REMOTE_PROTOCOL_INFORMATION structure. This structure contains protocol-specific information for files accessed over a network, such as SMB version, capabilities, and server/share details. This is primarily used by network redirectors and applications interacting with remote files.
Path, Result, FileInformationClass (FileRemoteProtocolInformation), Length, Buffer. NtQueryInformationFile / ZwQueryInformationFile. Generates IRP_MJ_QUERY_INFORMATION. Parameters.QueryFile.FileInformationClass is FileRemoteProtocolInformation. I/O Manager, Network Redirector (e.g., mrxsmb.sys), File System Driver Stack on the remote server.
Registry RegOpenKey
  • Action: Open an existing registry key.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: The Configuration Manager resolves the provided key path (e.g., \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion). It performs access checks based on the DesiredAccess parameter (e.g., KEY_READ, KEY_WRITE, KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS) against the key's Security Descriptor (DACL/SACL). If successful, a handle to the KEY_OBJECT is returned to the caller. The KEY_OBJECT is a kernel structure representing the opened key, providing access to its values and subkeys stored within the registry hive file (e.g., SOFTWARE, SYSTEM, NTUSER.DAT). NtOpenKeyEx allows OpenOptions such as REG_OPTION_OPEN_LINK (to open symbolic link keys) or REG_OPTION_BACKUP_RESTORE (for backup/restore access, bypassing some security checks if privileges allow). The key object contains cached information about the key, like its subkey and value counts, and pointers to cell indexes in the hive.
Path (Key Name), Result, Desired Access, Options (for Ex version). NtOpenKey / ZwOpenKey , NtOpenKeyEx / ZwOpenKeyEx. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS values like RegNtPreOpenKey(Ex) / RegNtPostOpenKey(Ex). Callback receives structures like REG_PRE_OPEN_KEY_INFORMATION (contains PUNICODE_STRING CompleteName) or REG_POST_OPEN_KEY_INFORMATION (contains PUNICODE_STRING CompleteName, PVOID Object which is the KEY_OBJECT pointer, NTSTATUS Status). Configuration Manager (Registry - ntoskrnl.exe component).
Registry RegCreateKey
  • Action: Create a new registry key or open an existing one.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: If the key specified in ObjectAttributes (containing the path) does not exist, the Configuration Manager attempts to create it. This involves allocating new key cell(s) within the appropriate hive file, initializing the key cell with metadata (e.g., name, class, timestamps, security descriptor). A default Security Descriptor is typically inherited from the parent key unless one is explicitly provided in ObjectAttributes->SecurityDescriptor. If the key already exists, it is opened. The Disposition output parameter of NtCreateKey indicates REG_CREATED_NEW_KEY or REG_OPENED_EXISTING_KEY. CreateOptions (e.g., REG_OPTION_VOLATILE for non-persistent keys, REG_OPTION_NON_VOLATILE for persistent keys, REG_OPTION_CREATE_LINK for symbolic links) influence the key's properties and storage. A handle to the KEY_OBJECT is returned. The KEY_OBJECT is populated with information about the key.
Path (Key Name), Result, Desired Access, Options, Disposition. NtCreateKey / ZwCreateKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreCreateKey(Ex) / RegNtPostCreateKey(Ex). Callback receives structures like REG_PRE_CREATE_KEY_INFORMATION (contains PUNICODE_STRING CompleteName ) or REG_CREATE_KEY_INFORMATION (contains PUNICODE_STRING CompleteName, PVOID RootObject, CreateOptions, DesiredAccess, PULONG Disposition, PVOID *ResultObject etc. ), or REG_POST_CREATE_KEY_INFORMATION (contains PUNICODE_STRING CompleteName, PVOID Object, NTSTATUS Status ). Configuration Manager (Registry).
Registry RegCloseKey
  • Action: Close an open handle to a registry key.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: NtClose is called on the registry key handle. This decrements the handle count for the KEY_OBJECT in the current process. If the handle count for the object reaches zero across all processes, and its reference count (maintained by the Object Manager for kernel references) also reaches zero, the KEY_OBJECT structure in memory is deallocated. This does not necessarily mean the key data is immediately flushed from the hive cache to disk; RegFlushKey can be used for that. The key itself remains in the registry unless explicitly deleted.
Path (Key Name), Result. NtClose / ZwClose on a registry key handle. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreKeyHandleClose / RegNtPostKeyHandleClose. Callback receives REG_KEY_HANDLE_CLOSE_INFORMATION (contains PVOID Object). Configuration Manager (Registry), Object Manager.
Registry RegQueryValue
  • Action: Retrieve the data and type of a named value entry under an open registry key.
    Target Object: Registry KEY_OBJECT (handle must have KEY_QUERY_VALUE access ).
    System-Level Effect: Reads the data associated with the specified ValueName from the registry hive. The KeyValueInformationClass parameter of NtQueryValueKey determines the structure of the data returned: KeyValueBasicInformation (returns KEY_VALUE_BASIC_INFORMATION with TitleIndex, Type, NameLength, Name ), KeyValuePartialInformation (returns KEY_VALUE_PARTIAL_INFORMATION with TitleIndex, Type, DataLength, Data ), or KeyValueFullInformation (returns KEY_VALUE_FULL_INFORMATION with TitleIndex, Type, DataOffset, DataLength, NameLength, Name - data follows inline ). The data is copied from the hive cell containing the value entry into the caller-supplied KeyValueInformation buffer. The key's Last Access Time is not typically updated by this operation.
Path (Key Name), Value Name, Result, Type, Length (of data), Data. NtQueryValueKey / ZwQueryValueKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreQueryValueKey / RegNtPostQueryValueKey. Callback receives REG_QUERY_VALUE_KEY_INFORMATION (contains PVOID Object, PUNICODE_STRING ValueName, KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, PVOID KeyValueInformation, ULONG Length, PULONG ResultLength). Configuration Manager (Registry).
Registry RegSetValue
  • Action: Set or create a named value entry under an open registry key.
    Target Object: Registry KEY_OBJECT (handle must have KEY_SET_VALUE access ).
    System-Level Effect: Writes data to the value entry specified by ValueName. If the value entry exists, its data and type are overwritten with the new data and Type (e.g., REG_SZ, REG_DWORD, REG_BINARY, REG_EXPAND_SZ, REG_MULTI_SZ ). If the value entry does not exist, a new value entry is created within the key's value list in the hive structure. The data is written to the registry hive file (eventually, or if explicitly flushed). This operation updates the LastWriteTime metadata of the parent key.
Path (Key Name), Value Name, Result, Type, Length (of data), Data. NtSetValueKey / ZwSetValueKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreSetValueKey / RegNtPostSetValueKey. Callback receives REG_SET_VALUE_KEY_INFORMATION (contains PVOID Object, PUNICODE_STRING ValueName, ULONG TitleIndex, ULONG Type, PVOID Data, ULONG DataSize). Configuration Manager (Registry).
Registry RegDeleteKey
  • Action: Delete a specified registry key.
    Target Object: Registry KEY_OBJECT (handle must have DELETE access ).
    System-Level Effect: Removes the specified key from the registry hive. For the operation to succeed, the key must not have any subkeys (i.e., it is not a recursive delete). All value entries under the key are also removed. This involves modifying the parent key's subkey list data in the hive and marking the key cell(s) as free or unlinked. The handle to the deleted key becomes invalid. The key's LastWriteTime is updated before deletion.
Path (Key Name), Result. NtDeleteKey / ZwDeleteKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreDeleteKey / RegNtPostDeleteKey. Callback receives REG_DELETE_KEY_INFORMATION (contains PVOID Object). Configuration Manager (Registry).
Registry RegDeleteValue
  • Action: Delete a named value entry from an open registry key.
    Target Object: Registry KEY_OBJECT (handle must have KEY_SET_VALUE access, as KEY_SET_VALUE includes permission to delete values ).
    System-Level Effect: Removes the value entry specified by ValueName and its associated data from the key's value list within the registry hive. This involves modifying the key cell's value list and potentially freeing data cells in the hive. Updates the LastWriteTime metadata of the parent key.
Path (Key Name), ValueName, Result. NtDeleteValueKey / ZwDeleteValueKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreDeleteValueKey / RegNtPostDeleteValueKey. Callback receives REG_DELETE_VALUE_KEY_INFORMATION (contains PVOID Object, PUNICODE_STRING ValueName). Configuration Manager (Registry).
Registry RegEnumKey
  • Action: Enumerate the subkeys of an open registry key, one at a time.
    Target Object: Registry KEY_OBJECT (handle must have KEY_ENUMERATE_SUB_KEYS access ).
    System-Level Effect: Retrieves information about one subkey at each call, specified by the zero-based Index. The KeyInformationClass parameter of NtEnumerateKey determines the structure of the data returned for the subkey (e.g., KeyBasicInformation for KEY_BASIC_INFORMATION containing LastWriteTime, NameLength, Name ; KeyNodeInformation for KEY_NODE_INFORMATION containing LastWriteTime, ClassOffset, ClassLength, NameLength, Name ; KeyFullInformation for KEY_FULL_INFORMATION with more comprehensive details ). The Configuration Manager reads the subkey list associated with the parent key's cell in the hive.
Path (Key Name), Index, Result, Name (of enumerated subkey), KeyInformationClass. NtEnumerateKey / ZwEnumerateKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreEnumerateKey / RegNtPostEnumerateKey. Callback receives REG_ENUMERATE_KEY_INFORMATION (contains PVOID Object, ULONG Index, KEY_INFORMATION_CLASS KeyInformationClass, PVOID KeyInformation, ULONG Length, PULONG ResultLength). Configuration Manager (Registry).
Registry RegEnumValue
  • Action: Enumerate the value entries of an open registry key, one at a time.
    Target Object: Registry KEY_OBJECT (handle must have KEY_QUERY_VALUE access ).
    System-Level Effect: Retrieves information about one value entry at each call, specified by the zero-based Index. The KeyValueInformationClass parameter of NtEnumerateValueKey determines the structure of the returned data (e.g., KeyValueBasicInformation for KEY_VALUE_BASIC_INFORMATION ; KeyValuePartialInformation for KEY_VALUE_PARTIAL_INFORMATION ; KeyValueFullInformation for KEY_VALUE_FULL_INFORMATION ). The Configuration Manager reads the value list associated with the key's cell in the hive.
Path (Key Name), Index, Result, Name (of enumerated value), Type, Length, Data. NtEnumerateValueKey / ZwEnumerateValueKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreEnumerateValueKey / RegNtPostEnumerateValueKey. Callback receives REG_ENUMERATE_VALUE_KEY_INFORMATION (contains PVOID Object, ULONG Index, KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, PVOID KeyValueInformation, ULONG Length, PULONG ResultLength). Configuration Manager (Registry).
Registry RegQueryKey
  • Action: Retrieve information about the class of a registry key, and the number and sizes of its subkeys and values.
    Target Object: Registry KEY_OBJECT (handle generally needs KEY_QUERY_VALUE access, but not for KeyNameInformation or KeyHandleTagsInformation ).
    System-Level Effect: Retrieves metadata about the key itself, not its specific subkeys or values. The KeyInformationClass parameter of NtQueryKey determines the structure of data returned: KeyBasicInformation (KEY_BASIC_INFORMATION: LastWriteTime, NameLength, Name ), KeyNodeInformation (KEY_NODE_INFORMATION: includes class name info ), KeyFullInformation (KEY_FULL_INFORMATION: includes counts of subkeys/values, max name/value/class lengths, LastWriteTime, class name ), KeyNameInformation (KEY_NAME_INFORMATION: key name ). This information is read from the key's cell metadata in the hive. Useful for determining buffer sizes needed for subsequent enumeration calls.
Path (Key Name), Result, KeyInformationClass, Length, Buffer (containing specific KEY_XXX_INFORMATION structure). NtQueryKey / ZwQueryKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreQueryKey / RegNtPostQueryKey. Callback receives REG_QUERY_KEY_INFORMATION (contains PVOID Object, KEY_INFORMATION_CLASS KeyInformationClass, PVOID KeyInformation, ULONG Length, PULONG ResultLength). Configuration Manager (Registry).
Registry RegSetInfoKey
  • Action: Set metadata information for a specified registry key.
    Target Object: Registry KEY_OBJECT (handle must have KEY_SET_VALUE or appropriate write access depending on the information class being set ).
    System-Level Effect: Modifies metadata associated with the key based on the KeySetInformationClass parameter of NtSetInformationKey. Common classes: KeyWriteTimeInformation (sets KEY_WRITE_TIME_INFORMATION structure containing LastWriteTime; requires KEY_SET_VALUE ), KeyUserFlagsInformation (obsolete), KeyControlFlagsInformation (reserved ), KeySetVirtualizationInformation (sets KEY_SET_VIRTUALIZATION_INFORMATION with flags like EnableVirtualization, VirtualizePending; affects registry virtualization behavior for the key ). Changes are made to the key's cell metadata in the hive.
Path (Key Name), Result, KeySetInformationClass, Length, Buffer (containing specific KEY_SET_XXX_INFORMATION structure). NtSetInformationKey / ZwSetInformationKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreSetInformationKey / RegNtPostSetInformationKey. Callback receives REG_SET_INFORMATION_KEY_INFORMATION (contains PVOID Object, KEY_SET_INFORMATION_CLASS KeySetInformationClass, PVOID KeySetInformation, ULONG KeySetInformationLength). Configuration Manager (Registry).
Registry RegQueryKeySecurity
  • Action: Query the security descriptor of a registry key.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: Retrieves a copy of the key's Security Descriptor. The SecurityInformation parameter to NtQuerySecurityObject specifies which parts to retrieve (Owner, Group, DACL, SACL). Requires appropriate access rights on the handle (e.g., READ_CONTROL for Owner/Group/DACL, ACCESS_SYSTEM_SECURITY for SACL ). The Security Descriptor is part of the key's metadata stored in its cell in the hive. The returned SECURITY_DESCRIPTOR is in self-relative format.
Path (Key Name), Result, SecurityInformation, Length, Buffer (receives SECURITY_DESCRIPTOR). NtQuerySecurityObject / ZwQuerySecurityObject. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreQueryKeySecurity / RegNtPostQueryKeySecurity. Callback receives REG_QUERY_KEY_SECURITY_INFORMATION (contains PVOID Object, PSECURITY_INFORMATION SecurityInformation, PSECURITY_DESCRIPTOR SecurityDescriptor, PULONG LengthNeeded). Configuration Manager (Registry), Security Reference Monitor.
Registry RegSetKeySecurity
  • Action: Modify the security descriptor of a registry key.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: Updates the Security Descriptor (Owner, Group, DACL, and/or SACL) of the key. The SecurityInformation parameter to NtSetSecurityObject specifies which parts are being set. Requires appropriate access rights on the handle (e.g., WRITE_DAC to set DACL, WRITE_OWNER to set Owner/Group, ACCESS_SYSTEM_SECURITY to set SACL ). Changes are written to the key's metadata in its hive cell. This directly modifies the permissions controlling access to the key.
Path (Key Name), Result, SecurityInformation, SecurityDescriptor. NtSetSecurityObject / ZwSetSecurityObject. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreSetKeySecurity / RegNtPostSetKeySecurity. Callback receives REG_SET_KEY_SECURITY_INFORMATION (contains PVOID Object, PSECURITY_INFORMATION SecurityInformation, PSECURITY_DESCRIPTOR SecurityDescriptor). Configuration Manager (Registry), Security Reference Monitor.
Registry RegLoadKey
  • Action: Load a registry hive file into the live registry under a specified key path.
    Target Object: Registry KEY_OBJECT (for the parent key under which the hive is loaded, and a new KEY_OBJECT for the root of the loaded hive), Hive File (on disk).
    System-Level Effect: Reads a hive file (specified by SourceFile parameter to NtLoadKeyEx) from disk and links it into the live registry namespace under TargetKey. This makes the contents of the hive file (keys, values, security descriptors) accessible as part of the active registry. The Configuration Manager creates a new KEY_OBJECT for the root of the loaded hive. The operation typically requires specific privileges (e.g., SeRestorePrivilege). Flags for NtLoadKeyEx (e.g., REG_NO_LAZY_FLUSH, REG_WHOLE_HIVE_VOLATILE) control aspects of how the hive is loaded and managed. The SourceFile is read by the file system.
Path (Target Key Name), Source File Path, Result, Flags. NtLoadKey / ZwLoadKey, NtLoadKeyEx / ZwLoadKeyEx. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreLoadKey / RegNtPostLoadKey. Callback receives REG_LOAD_KEY_INFORMATION (contains PVOID Object (parent key object if loading under an existing key, or NULL), PUNICODE_STRING KeyName (target path), PUNICODE_STRING SourceFile, ULONG Flags, PHANDLE RootHandle (out)). Configuration Manager (Registry), File System Driver Stack (to read the hive file).
Registry RegUnloadKey
  • Action: Unload a previously loaded registry hive from the live registry.
    Target Object: Registry KEY_OBJECT (representing the root of the hive to be unloaded).
    System-Level Effect: Detaches the specified hive (identified by TargetKey in NtUnloadKeyEx) from the live registry. Any changes made to the hive since it was loaded may or may not be flushed to the hive file on disk, depending on how it was loaded (e.g., REG_NO_LAZY_FLUSH) and system activity. The KEY_OBJECT for the hive root becomes invalid, and its contents are no longer accessible in the registry. This operation typically requires specific privileges (e.g., SeRestorePrivilege). All handles to keys within the unloaded hive become invalid.
Path (Key Name of hive root), Result. NtUnloadKey / ZwUnloadKey, NtUnloadKeyEx / ZwUnloadKeyEx. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreUnLoadKey / RegNtPostUnLoadKey. Callback receives REG_UNLOAD_KEY_INFORMATION (contains PVOID Object (hive root key object), PVOID UserEvent). Configuration Manager (Registry).
Registry RegFlushKey
  • Action: Write all modified information for a specific registry key and its subkeys to the persistent hive file on disk.
    Target Object: Registry KEY_OBJECT.
    System-Level Effect: Forces all cached modifications to the specified key and all its subkeys within its hive to be written out to the corresponding hive file on disk. This ensures data persistence in case of a system crash before a normal lazy flush occurs. This is a resource-intensive operation as it flushes the entire hive containing the key, not just the specified key.
Path (Key Name), Result. NtFlushKey / ZwFlushKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreFlushKey / RegNtPostFlushKey. Callback receives REG_FLUSH_KEY_INFORMATION (which is a typedef for REG_DELETE_KEY_INFORMATION, containing PVOID Object). Configuration Manager (Registry), File System Driver Stack (to write the hive file).
Registry RegQueryMultipleValueKey
  • Action: Retrieve data for multiple specified value entries under an open registry key in a single operation.
    Target Object: Registry KEY_OBJECT (handle must have KEY_QUERY_VALUE access).
    System-Level Effect: Reads data for an array of KEY_VALUE_ENTRY structures provided by the caller. Each KEY_VALUE_ENTRY specifies a ValueName to query. The data for all successfully queried values is packed into the caller-supplied ValueBuffer. The DataOffset and DataLength fields within each KEY_VALUE_ENTRY in the output (if the buffer is re-used or if ValueEntries is an in/out parameter in some contexts) would indicate where each value's data is located in ValueBuffer. This can be more efficient than multiple individual NtQueryValueKey calls for retrieving several values from the same key.
Path (Key Name), Result, Number of Values requested/returned, Buffer (containing KEY_VALUE_ENTRY array and concatenated value data). NtQueryMultipleValueKey / ZwQueryMultipleValueKey. Intercepted via CmRegisterCallbackEx using REG_NOTIFY_CLASS like RegNtPreQueryMultipleValueKey / RegNtPostQueryMultipleValueKey. Callback receives REG_QUERY_MULTIPLE_VALUE_KEY_INFORMATION (contains PVOID Object, PKEY_VALUE_ENTRY ValueEntries (input array), ULONG EntryCount, PVOID ValueBuffer (output buffer), PULONG BufferLength, PULONG RequiredBufferLength). Configuration Manager (Registry).
Process and Thread Process Create
  • Action: A new process is being created.
    Target Object: EPROCESS object (Executive Process Block).
    System-Level Effect: The kernel allocates and initializes a new EPROCESS structure and its embedded KPROCESS (Pcb). This includes assigning a unique Process ID (PID), creating an initial, minimal virtual address space (VAD tree), setting up a Process Environment Block (PEB) in the new process's user address space , inheriting handles from the parent process (if specified in creation flags), and creating the initial thread (ETHREAD/KTHREAD). A process access token, determining the security context, is duplicated from the parent or specified explicitly. Object Manager namespace entries for the process object are created. The PEB is populated with process parameters, image load information (Ldr), heap manager data, and other runtime details. The PPS_CREATE_NOTIFY_INFO structure passed to the notification routine contains ImageFileName, CommandLine, FileOpenNameAvailable, ParentProcessId, etc.
Image Path, Command Line, PID, Parent PID, Result, Session ID, Authentication ID, User. NtCreateUserProcess or older NtCreateProcess(Ex). Procmon uses PsSetCreateProcessNotifyRoutineEx or PsSetCreateProcessNotifyRoutine to register a PCREATE_PROCESS_NOTIFY_ROUTINE(_EX) callback. This callback receives ProcessId, ParentId, a BOOLEAN Create flag (TRUE for creation), and for the Ex version, a PPS_CREATE_NOTIFY_INFO structure. Process Manager (Kernel Executive component in ntoskrnl.exe), Object Manager, Memory Manager, Security Reference Monitor.
Process and Thread Process Start
  • Action: The initial thread of a newly created process begins execution in user mode.
    Target Object: EPROCESS, ETHREAD (initial thread).
    System-Level Effect: This event typically signifies that the core process initialization by the kernel and loader (ntdll.dll in user mode) is complete enough for the first thread to transition to user mode and begin executing the program's entry point (e.g., main or WinMain). The PEB is fully initialized, initial system DLLs (like ntdll.dll, kernel32.dll, KernelBase.dll) are mapped, and the loader is resolving static imports. The thread's user-mode stack is set up, and its context points to the user-mode start address.
PID, Parent PID, Image Path, Command Line, User, Session ID. Captured via the PCREATE_PROCESS_NOTIFY_ROUTINE(_EX) callback (from PsSetCreateProcessNotifyRoutine(Ex) ), specifically when the Create flag is TRUE and the PPS_CREATE_NOTIFY_INFO->CreationStatus indicates success, just before or as the initial thread is released to run user code. Process Manager (Kernel), Loader (ntdll.dll).
Process and Thread Process Exit
  • Action: A process is terminating.
    Target Object: EPROCESS.
    System-Level Effect: All threads in the process have exited or are being forcibly terminated. The kernel reclaims resources associated with the process: virtual address space is deallocated, FILE_OBJECT handles in its handle table are closed (triggering IRP_MJ_CLEANUP/IRP_MJ_CLOSE for those objects), user-mode memory is freed, GDI objects are cleaned up, etc. The EPROCESS object itself is rundown and eventually deallocated. The process exit status is recorded in the EPROCESS structure and made available to waiting parent processes. The Object Manager removes references to the process object.
PID, Exit Status, CPU Time (User and Kernel), Private Bytes, Working Set Size, Handle Count. Captured via the PCREATE_PROCESS_NOTIFY_ROUTINE(_EX) callback (from PsSetCreateProcessNotifyRoutine(Ex) ), when the Create flag is FALSE. The PPS_CREATE_NOTIFY_INFO (if Ex version) will have its relevant fields indicating exit. Process Manager (Kernel), Object Manager, Memory Manager, I/O Manager (for handle cleanup).
Process and Thread Thread Create
  • Action: A new thread is being created within a process.
    Target Object: ETHREAD object (Executive Thread Block).
    System-Level Effect: The kernel allocates and initializes a new ETHREAD structure and its embedded KTHREAD (Kernel Thread object). This involves allocating memory for kernel and user stacks (if not specified to use existing ones), assigning a unique Thread ID (TID) within the process, setting up a Thread Environment Block (TEB) in user address space , and preparing the thread's initial context (e.g., start address (StartRoutine), stack pointer, initial argument (Argument)). The thread is added to the parent process's thread list (in EPROCESS->ThreadListHead). The thread's initial state might be suspended (THREAD_CREATE_FLAGS_CREATE_SUSPENDED). Security context (impersonation token) can be set.
TID, PID, Thread Start Address, Stack Base, Stack Limit, User Stack Base, User Stack Limit, Win32 Start Address. NtCreateThreadEx or older NtCreateThread. Procmon uses PsSetCreateThreadNotifyRoutine to register a PCREATE_THREAD_NOTIFY_ROUTINE callback. This callback receives ProcessId, ThreadId, and a BOOLEAN Create flag (TRUE for creation). Process Manager (Kernel), Object Manager, Memory Manager.
Process and Thread Thread Exit
  • Action: A thread is terminating.
    Target Object: ETHREAD.
    System-Level Effect: The thread's execution stops. Its kernel stack is deallocated, user stack may be released (if not the initial thread's stack and not managed externally), and the TEB is cleaned up. Any thread-local storage (TLS) destructors are called. The ETHREAD object is rundown, its reference count decremented, and it's eventually deallocated by the Object Manager. If this is the last thread in a process, its exit triggers the process exit sequence. The thread's exit status is recorded in the ETHREAD structure.
TID, PID, Exit Status, Kernel Time, User Time, Context Switches. Captured via the PCREATE_THREAD_NOTIFY_ROUTINE callback (from PsSetCreateThreadNotifyRoutine ), when the Create flag is FALSE. Process Manager (Kernel), Object Manager, Memory Manager.
Process and Thread Load Image
  • Action: An executable file (EXE, DLL, SYS, etc.) is mapped into a process's address space or kernel address space.
    Target Object: SECTION_OBJECT (for the image file), Process Address Space (for user-mode images), Kernel Address Space (for kernel-mode images/drivers).
    System-Level Effect: The Memory Manager maps the image file into the virtual address space. This involves creating a SECTION_OBJECT backed by the image file (typically with SEC_IMAGE attribute) if one doesn't already exist for sharing. PE headers are parsed by the loader (ntdll.dll for user-mode, ntoskrnl.exe for kernel-mode drivers). For user-mode DLLs/EXEs, imports are resolved, base relocations are applied if the image is not loaded at its preferred base address, and DLL entry points (DllMain with DLL_PROCESS_ATTACH or DLL_THREAD_ATTACH) are called. For kernel drivers (.sys), their DriverEntry routine is called. The IMAGE_INFO or IMAGE_INFO_EX structure passed to the notify routine provides details like ImageBase (load address), ImageSize, ImageChecksum, TimeDateStamp, SystemModeImage (TRUE for kernel, FALSE for user), ImageSignatureLevel, and ImageSignatureType.
Image Path, Image Base, Image Size, Signed, Signature Level, Signature Type, PID (of loading process), Version, Company, Description. Procmon uses PsSetLoadImageNotifyRoutine to register a PLOAD_IMAGE_NOTIFY_ROUTINE callback. This callback receives FullImageName (UNICODE_STRING), ProcessId (for user-mode loads), and a pointer to an IMAGE_INFO structure. Memory Manager (Kernel), Process Manager (Kernel), Loader (ntdll.dll for user-mode images; I/O Manager for kernel-mode drivers).
Network Activity TCP Connect
  • Action: Initiate an outgoing TCP connection attempt.
    Target Object: Network Endpoint (internally, a socket object and associated TCP Control Block - TCB).
    System-Level Effect: A process, typically via Winsock API (connect()), requests to establish a TCP connection to a remote IP address and port. afd.sys (Ancillary Function Driver) handles the user-mode request and passes it to tcpip.sys. tcpip.sys initiates the TCP three-way handshake (SYN, SYN-ACK, ACK) by sending a SYN packet. Kernel structures representing the TCP connection (e.g., TCB) are allocated and initialized. The connection state transitions from CLOSED/LISTEN to SYN-SENT. Socket options (e.g., SO_RCVBUF, SO_SNDBUF, TCP_NODELAY) influence TCB parameters.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, SequenceNumber, Sent, Path (often n/a or process path). Winsock connect() API. Intercepted via Event Tracing for Windows (ETW) events from kernel providers like Microsoft-Windows-Kernel-Network (for TCP/IP events) or Microsoft-Windows-Winsock-AFD (for AFD events). tcpip.sys handles TCP protocol logic. afd.sys, tcpip.sys, Network Interface Card (NIC) Driver.
Network Activity TCP Accept
  • Action: Accept an incoming TCP connection on a listening socket.
    Target Object: Network Endpoint (listening socket and a new socket for the established connection).
    System-Level Effect: A process, via Winsock API (accept()), accepts an incoming connection request that has completed the three-way handshake on a socket previously set to listen (listen()). afd.sys and tcpip.sys manage the queue of completed connections for the listening socket. A new socket (and associated kernel endpoint structures, including a new TCB) is typically created to handle the established connection, inheriting properties from the listening socket. The original socket remains in the listening state. The connection state for the new socket becomes ESTABLISHED.
PID, Source IP (of client), Source Port (of client), Destination IP (local), Destination Port (local), Result, SequenceNumber, Received, Path. Winsock accept() API. Intercepted via ETW events (e.g., Microsoft-Windows-Kernel-Network, Microsoft-Windows-Winsock-AFD). tcpip.sys handles TCP protocol logic. afd.sys, tcpip.sys, NIC Driver.
Network Activity TCP Disconnect
  • Action: Terminate an established TCP connection.
    Target Object: Network Endpoint (socket).
    System-Level Effect: A process, via Winsock (closesocket() or shutdown()), initiates the termination of a TCP connection. afd.sys and tcpip.sys handle the TCP four-way handshake (FIN, ACK, FIN, ACK) or an RST if abrupt. The TCB associated with the connection transitions through states like FIN_WAIT_1, FIN_WAIT_2, TIME_WAIT, or CLOSE_WAIT before reaching CLOSED. Resources associated with the TCB and socket are released.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, SequenceNumber, Sent/Received. Winsock closesocket() or shutdown() API. Intercepted via ETW. tcpip.sys handles TCP protocol logic. afd.sys, tcpip.sys, NIC Driver.
Network Activity TCP Receive
  • Action: Receive data over an established TCP connection.
    Target Object: Network Endpoint (socket).
    System-Level Effect: Data arrives from the remote endpoint. tcpip.sys processes incoming TCP segments, reassembles them into a byte stream, performs acknowledgement, and places the data into the socket's receive buffer. When a process calls a Winsock receive function (e.g., recv()), afd.sys retrieves data from this buffer and copies it to the application's buffer. The TCB tracks sequence numbers, window sizes, and other TCP state.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, SequenceNumber, Length (of data received), Data (first few bytes often shown). Winsock recv(), WSARecv() etc. APIs. Intercepted via ETW. tcpip.sys handles TCP protocol logic. afd.sys, tcpip.sys, NIC Driver.
Network Activity TCP Send
  • Action: Send data over an established TCP connection.
    Target Object: Network Endpoint (socket).
    System-Level Effect: Data from an application buffer is passed via Winsock (e.g., send()) to afd.sys, then to tcpip.sys. tcpip.sys segments the data into TCP packets, adds TCP headers (source/dest port, sequence/ack numbers, flags), and passes them to the IP layer for transmission. The TCB manages send buffers, sequence numbers, retransmission timers, and congestion control state.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, SequenceNumber, Length (of data sent), Data (first few bytes often shown). Winsock send(), WSASend() etc. APIs. Intercepted via ETW. tcpip.sys handles TCP protocol logic. afd.sys, tcpip.sys, NIC Driver.
Network Activity TCP Reconnect
  • Action: This operation is not a standard TCP primitive like connect or accept. Procmon might show this if a higher-level protocol or application logic attempts to re-establish a dropped connection. This would typically involve a new TCP Connect operation after a TCP Disconnect or timeout.
    Target Object: Network Endpoint.
    System-Level Effect: Involves closing or recognizing the failure of a previous connection, followed by initiating a new connection attempt. This would manifest as a sequence of TCP Disconnect (or timeout) followed by TCP Connect operations rather than a single "Reconnect" kernel operation.
PID, Source IP, Source Port, Destination IP, Destination Port, Result. Application-level logic or higher-level network library behavior, ultimately using Winsock APIs like connect(). Intercepted via ETW as separate connect events. Application, Winsock, afd.sys, tcpip.sys.
Network Activity TCP Retransmit
  • Action: TCP layer retransmits unacknowledged data segments.
    Target Object: TCP Control Block (TCB) for an existing connection.
    System-Level Effect: tcpip.sys detects that previously sent TCP segments have not been acknowledged by the remote host within the retransmission timeout (RTO) period. It resends these segments from its retransmission queue. This is an internal mechanism of TCP for reliable data delivery and is managed by tcpip.sys. It impacts network traffic and can indicate network congestion or packet loss.
PID (of process owning the socket), Source IP, Source Port, Destination IP, Destination Port, SequenceNumber, Length. Internal to tcpip.sys. Intercepted via ETW events from Microsoft-Windows-Kernel-Network that specifically flag retransmissions. tcpip.sys.
Network Activity TCP TCPCopy
  • Action: This is likely related to data being copied within the TCP/IP stack, possibly from application buffers to kernel buffers, or between kernel buffers (e.g., for segmentation/reassembly, or loopback). It's not a standard TCP operation name seen by applications.
    Target Object: Kernel memory buffers, Socket buffers.
    System-Level Effect: Data movement within tcpip.sys or between afd.sys and tcpip.sys related to TCP send/receive processing. Could involve copying data to/from NIC driver buffers. This is an internal implementation detail of the networking stack.
PID, Source/Destination context (may not be IP/Port), Length. Internal kernel operations within afd.sys or tcpip.sys. Intercepted via specific, low-level ETW events if available, or inferred by Procmon's network filter driver if it hooks at a point where such copies are visible. afd.sys, tcpip.sys.
Network Activity UDP Send
  • Action: Send a UDP datagram.
    Target Object: Network Endpoint (socket).
    System-Level Effect: A process, via Winsock (sendto() or send()), sends a UDP datagram. afd.sys passes the request to tcpip.sys (specifically its UDP component). UDP is connectionless, so no handshake occurs. tcpip.sys constructs a UDP packet (source/dest port, length, checksum) and an IP header, then passes it to the NIC driver for transmission. Data may be fragmented at the IP layer if too large for network MTU.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, Length, Data (first few bytes). Winsock sendto(), send() APIs. Intercepted via ETW (Microsoft-Windows-Kernel-Network, Microsoft-Windows-Winsock-AFD). tcpip.sys handles UDP protocol. afd.sys, tcpip.sys, NIC Driver.
Network Activity UDP Receive
  • Action: Receive a UDP datagram.
    Target Object: Network Endpoint (socket).
    System-Level Effect: A UDP datagram arrives at the NIC. The NIC driver passes it up to tcpip.sys. tcpip.sys validates the IP and UDP headers (checksum). If a socket is bound to the destination port, the datagram payload is placed in that socket's receive buffer. When a process calls a Winsock receive function (e.g., recvfrom()), afd.sys retrieves the datagram from the socket buffer and copies it to the application's buffer.
PID, Source IP, Source Port, Destination IP, Destination Port, Result, Length, Data (first few bytes). Winsock recvfrom(), recv() APIs. Intercepted via ETW. tcpip.sys handles UDP protocol. afd.sys, tcpip.sys, NIC Driver.
Profiling Events Process Profiling
  • Action: Periodic sampling of thread execution statistics.
    Target Object: ETHREAD / EPROCESS.
    System-Level Effect: When enabled (Options -> Enable Profiling Events), Procmon's driver periodically (default 100ms, configurable via /Profiling command line switch ) samples all active threads. For each thread, it records kernel CPU time, user CPU time, and the number of context switches that have occurred since the thread's previous profiling event or since thread creation. This information is obtained by querying kernel performance counters and thread-specific data structures (KTHREAD contains KernelTime, UserTime, ContextSwitches). This does not trace individual function calls but gives an overview of CPU consumption by threads.
PID, TID, User Time, Kernel Time, Context Switches. Procmon driver directly queries kernel structures or uses kernel APIs like NtQuerySystemInformation with SystemPerformanceInformation or per-thread information classes. Process Manager (Kernel), Scheduler.
 

3. Detailed Explanation of Capture Mechanisms

Process Monitor employs a sophisticated array of kernel-mode techniques to intercept and record system activity. Its ability to provide a comprehensive view of system behavior stems from its deep integration with the Windows operating system, primarily through a custom kernel-mode driver (typically named PROCMONXX.SYS, where XX is a version number). This driver utilizes several distinct mechanisms depending on the class of operation being monitored.

3.1. File System Operations

Procmon's file system monitoring capabilities are predominantly implemented using a file system minifilter driver. This driver registers with the Filter Manager (FltMgr.sys), a kernel component that provides a structured framework for third-party drivers to observe and modify I/O requests targeting file systems.

  • Filter Manager and Altitudes: The Filter Manager allows multiple minifilters to attach to the file system stack for a given volume. Each minifilter is assigned a unique altitude, which is a numerical value determining its position in the I/O stack relative to other filters. A lower numerical altitude means the driver is positioned closer to the file system, while a higher altitude places it further away, closer to the I/O Manager. Procmon's driver registers itself within an appropriate load order group, likely "FSFilter Activity Monitor" (altitude range 360000-389999 ), to ensure it can see I/O requests before or after other filters like antivirus or encryption drivers. The altitude is crucial as it dictates the order in which filters process IRPs.
  • IRP Interception: Once registered, Procmon's minifilter can intercept I/O Request Packets (IRPs) for various file system operations. Key IRP major functions monitored include:
    • IRP_MJ_CREATE: Captured for CreateFile operations. The minifilter's pre-operation callback (PFLT_PRE_OPERATION_CALLBACK) can inspect parameters like DesiredAccess, CreateOptions, CreateDisposition, and FileName from the FLT_CALLBACK_DATA structure (specifically Data->Iopb->Parameters.Create). Post-operation callbacks (PFLT_POST_OPERATION_CALLBACK) can see the result of the operation, including the IoStatus.Status and IoStatus.Information (e.g., FILE_CREATED, FILE_OPENED).
    • IRP_MJ_READ and IRP_MJ_WRITE: Captured for ReadFile and WriteFile operations. Callbacks can inspect parameters like Length, ByteOffset, and buffer details (via MdlAddress for direct I/O or by accessing system buffers for buffered I/O).
    • IRP_MJ_SET_INFORMATION and IRP_MJ_QUERY_INFORMATION: Captured for operations like SetBasicInformationFile, QueryNameInformationFile, etc. The FileInformationClass parameter dictates the specific information being set or queried.
    • IRP_MJ_DIRECTORY_CONTROL: Captured for QueryDirectory (IRP_MN_QUERY_DIRECTORY) and NotifyChangeDirectory (IRP_MN_NOTIFY_CHANGE_DIRECTORY).
    • IRP_MJ_CLEANUP and IRP_MJ_CLOSE: Captured for CloseFile operations, allowing observation of handle closure and resource deallocation.
    • IRP_MJ_QUERY_SECURITY and IRP_MJ_SET_SECURITY: Captured for QuerySecurityFile and SetSecurityFile operations, involving SECURITY_INFORMATION and SECURITY_DESCRIPTOR structures.
    • IRP_MJ_DEVICE_CONTROL and IRP_MJ_FILE_SYSTEM_CONTROL: Captured for DeviceIoControl and FileSystemControl operations, respectively, allowing inspection of IOCTL and FSCTL codes.
    • IRP_MJ_LOCK_CONTROL: Captured for LockFile and UnlockFileSingle operations (IRP_MN_LOCK, IRP_MN_UNLOCK_SINGLE).
    • IRP_MJ_FLUSH_BUFFERS: Captured for FlushBuffersFile.
  • Data Structures: The minifilter accesses IRP parameters through the FLT_CALLBACK_DATA and FLT_IO_PARAMETER_BLOCK structures provided by the Filter Manager. For example, Data->Iopb->TargetFileObject provides the FILE_OBJECT.

3.2. Registry Operations

Procmon monitors registry activity by registering a registry filtering callback routine with the Configuration Manager (the kernel component responsible for the registry).

  • CmRegisterCallbackEx: The primary mechanism is the CmRegisterCallbackEx function. This function allows a driver to register a RegistryCallback routine. Similar to file system minifilters, an Altitude string is provided to determine the callback's position relative to other registered registry filters, ensuring an orderly notification sequence.
  • REG_NOTIFY_CLASS and Callback Structures: The RegistryCallback routine is invoked for various registry operations, identified by a REG_NOTIFY_CLASS enumeration value passed as an argument. This enumeration includes values for pre- and post-notifications for operations such as:
    • Key creation: RegNtPreCreateKey(Ex), RegNtPostCreateKey(Ex)
    • Key opening: RegNtPreOpenKey(Ex), RegNtPostOpenKey(Ex)
    • Value setting: RegNtPreSetValueKey, RegNtPostSetValueKey
    • Value querying: RegNtPreQueryValueKey, RegNtPostQueryValueKey
    • Key deletion: RegNtPreDeleteKey, RegNtPostDeleteKey
    • Value deletion: RegNtPreDeleteValueKey, RegNtPostDeleteValueKey
    • Key enumeration: RegNtPreEnumerateKey, RegNtPostEnumerateKey
    • Value enumeration: RegNtPreEnumerateValueKey, RegNtPostEnumerateValueKey
    • Querying key information: RegNtPreQueryKey, RegNtPostQueryKey
    • Setting key information: RegNtPreSetInformationKey, RegNtPostSetInformationKey
    • Querying/setting security: RegNtPreQueryKeySecurity, RegNtPostQueryKeySecurity, RegNtPreSetKeySecurity, RegNtPostSetKeySecurity
    • Loading/unloading hives: RegNtPreLoadKey, RegNtPostLoadKey, RegNtPreUnLoadKey, RegNtPostUnLoadKey
    • Flushing keys: RegNtPreFlushKey, RegNtPostFlushKey
    • Querying multiple values: RegNtPreQueryMultipleValueKey, RegNtPostQueryMultipleValueKey
    • Closing key handles: RegNtPreKeyHandleClose, RegNtPostKeyHandleClose For each notification type, a specific structure (e.g., REG_PRE_CREATE_KEY_INFORMATION , REG_POST_SET_VALUE_KEY_INFORMATION , REG_QUERY_VALUE_KEY_INFORMATION ) is passed to the callback, containing operation-specific parameters like the key name, value name, data, desired access, etc. Procmon's driver inspects these structures to log the event details.

3.3. Process and Thread Operations

Monitoring of process and thread creation, deletion, and image loading is achieved through dedicated kernel notification routines:

  • Process Creation/Deletion: PsSetCreateProcessNotifyRoutineEx (or the older PsSetCreateProcessNotifyRoutine ) allows a driver to register a callback (PCREATE_PROCESS_NOTIFY_ROUTINE_EX). This callback is invoked by the Process Manager whenever a process is created or exits.
    • For creation, the callback receives the ProcessId of the new process, its ParentId, and a PPS_CREATE_NOTIFY_INFO structure (for the Ex version) containing detailed information such as the image file name (ImageFileName), command line (CommandLine), and creation status.
    • For exit, the Create flag passed to the callback is FALSE.
  • Thread Creation/Deletion: PsSetCreateThreadNotifyRoutine registers a callback (PCREATE_THREAD_NOTIFY_ROUTINE) that is notified when a thread is created or terminates. The callback receives the ProcessId and ThreadId, and a BOOLEAN flag indicating creation or deletion.
  • Image Loading: PsSetLoadImageNotifyRoutine registers a callback (PLOAD_IMAGE_NOTIFY_ROUTINE) that is invoked whenever an executable image (EXE, DLL, SYS) is mapped into memory (either user or kernel space). The callback receives the FullImageName (UNICODE_STRING), the ProcessId into which the image is loaded (0 for kernel-mode images), and a pointer to an IMAGE_INFO or IMAGE_INFO_EX structure. This structure provides the image's base address, size, signature level, and other properties.

3.4. Network Activity

Procmon captures network activity, specifically TCP and UDP operations, primarily by leveraging Event Tracing for Windows (ETW).

  • ETW Providers: Windows includes several ETW providers that emit detailed events related to network operations. Key providers include:
    • Microsoft-Windows-Kernel-Network: Provides low-level TCP/IP events, including connection establishment, data transfer (send/receive), disconnections, and retransmissions.
    • Microsoft-Windows-Winsock-AFD: Provides events from the Ancillary Function Driver (afd.sys), which sits between user-mode Winsock applications and the kernel-mode TCP/IP stack.
  • ETW Consumers: Procmon's driver acts as an ETW consumer for these network events. It creates an ETW trace session, enables the relevant providers and keywords (event types), and processes the real-time event stream. Each ETW event contains a structured payload with operation-specific data (e.g., source/destination IP addresses and ports, data length, sequence numbers for TCP). Procmon parses this payload to display network operations.
  • Windows Filtering Platform (WFP): While ETW is a primary source, WFP also provides extensive capabilities for network traffic inspection and filtering at various layers of the network stack. It's plausible Procmon might also leverage WFP callout drivers for certain network data, although ETW is more commonly cited for its general network activity logging.

3.5. Profiling Events

Profiling events in Procmon provide a periodic snapshot of thread CPU usage and context switches.

  • Kernel/Thread Data Structures: Procmon's driver likely accesses kernel data structures associated with each thread (KTHREAD or ETHREAD) that store performance counters. The KTHREAD structure, for instance, maintains fields for KernelTime and UserTime (accumulated CPU time spent in kernel and user mode, respectively) and ContextSwitches.
  • Periodic Sampling: When profiling is enabled, the driver periodically iterates through active threads in the system. For each thread, it queries these performance metrics. The difference between the current values and the previously sampled values (or initial values for a new thread) represents the activity during that sampling interval.
  • API/Mechanism: This could involve direct reading of these KTHREAD fields (requiring kernel privileges and careful synchronization) or using kernel APIs like NtQuerySystemInformation with specific information classes that expose thread performance data, or KeQueryRuntimeThread.

By combining these diverse kernel-mode interception techniques, Process Monitor achieves its comprehensive system monitoring capabilities, providing a detailed trace of system events that is invaluable for diagnostics, troubleshooting, and security analysis.

4. Limitations of Procmon

Despite its extensive capabilities, Process Monitor is not without limitations. Understanding these constraints is crucial for accurate interpretation of its output and for knowing when alternative tools or techniques might be necessary.

4.1. File System Operations

  • Boot-Time Activity (Early Boot): While Procmon offers boot logging , it relies on its driver (PROCMONXX.SYS) being loaded. Operations occurring very early in the boot process, before the Procmon driver itself is initialized by the Filter Manager (FltMgr.sys), may not be captured. This includes activities by the bootloader, ntoskrnl.exe during its earliest initialization phases, and critical boot-start drivers loaded before FltMgr.sys and Procmon's driver.
  • IRPs Bypassing FltMgr.sys: Certain specialized I/O operations or IRPs generated by kernel components might, in rare cases, bypass the standard Filter Manager stack where Procmon's minifilter resides. This is uncommon for standard file I/O but could occur with direct device interactions or non-standard FSDs.
  • Data Content: Procmon logs metadata about file operations (e.g., path, offset, length) but typically does not log the actual data content of ReadFile or WriteFile operations by default, primarily for performance and log size reasons. While some data might be shown in the detail view for small operations, full data capture is not its design.
  • Memory-Mapped I/O: While CreateFileMapping (backed by NtCreateSection) is captured, the subsequent data accesses via direct memory manipulation of the mapped view are not logged as distinct ReadFile or WriteFile operations by Procmon. Only the initial mapping and eventual unmapping/cache flushes might be visible. Page faults satisfied from the mapped file might appear as Paging I/O if the "Show Paging File I/O" option is enabled, but these are distinct from explicit file read operations.
  • Cache Manager Operations: Internal operations performed by the Cache Manager (e.g., read-aheads, lazy writes) are generally not directly visible as distinct Procmon events unless they result in IRPs being sent to the FSD that Procmon intercepts. The effects (e.g., data being written to disk later) are visible, but the internal Cache Manager decision-making is not.
  • ReFS Dev Drives: Some user reports suggest that by default, Procmon (as of version 4.01) might not capture all file system events on Windows Dev Drives formatted with ReFS without specific configuration or due to how ReFS interacts with filter drivers for these specialized volumes.
  • Filter Conflicts/Ordering: If another filter driver at a similar or conflicting altitude improperly