Procmon64 vs procmon64a driver#
Hooking with a driver is always more reliable and accurate. Is it better than using kernel drivers? Not generally. The event data is displayed as they come in. ProcMonX creates a real time session (no automatic logging to file) and registers for the events the user requests (the current list is small, more events will follow in subsequent versions). To get a sense of the number of providers use logman query providers in a command window.
Procmon64 vs procmon64a windows#
Windows provides many providers out of the box, each exposing a rich set of events.
These events can be logged to a file (.ETL extension) and then analyzed, or alternatively logged in real time to listening consumers. In ETW, providers spit out events that ETW consumers consume. ProcMonX, on the other hand, uses Event Tracing for Windows (ETW), a diagnostics and logging mechanism that existed since Windows 2000. The upside to using a driver is the ability to get the most accurate data, since some form of hooking is involved. So why doesn’t ProcMon provide the same range of events? In fact, the number of possible events is staggering, since there are many events exposed by the NT kernel provider, and the tool could be expanded to include other providers. ProcMonX provides information on similar activities to ProcMon, but adds many more events, such as networking, ALPC and memory.
Yesterday I released the first preview of a tool called Process Monitor X (ProcMonX), as a possible alternative to ProcMon. This tool helped me many times in diagnosing issues or just understanding what’s going on in a particular scenario. The (now classic) Process Monitor tool from Sysinternals allows watching important activities on a system: process and thread creation/termination, image loading/unloading, file system operations and registry operations (and some profiling events).
0 kommentar(er)
