I'm not familiar with the Windows version of ProcMon, but judging by the Linux version, that looks like it's primarily replicating the function of `strace` in a CLI GUI.
It's not quite strace, ProcMon also does network traffic stuff too. I used it quite a bit when my job was trying to shove proprietary (usually academic, usually engineering-related) software installers into a shape that we could make silently install. ProcMon was one of our first resorts whenever an installer would inevitably mysteriously crash when it ran inside an SCCM-managed installation of windows. Which. Was. OFTEN.
Sorry, it's been over a decade now and I still have nightmares sometimes. But yeah procmon is cool.
I do other sysadmin now but the job of getting whatever random vendor's installer into an SCCM deployable state required tools to see just WTF they were doing.
I recall one .exe installer, unzipping to an MSI, which installed the program files but then ran .bat file to run three separate driver installers for the associated hardware. And I had to get it all working in AppV.
I don't use Procmon much now as my work has changed, but I still consider it a good friend.
I am glad linux has other ways to do it but as a linux noob, I'd try procmon first if I had to.
Yes, ProcMon is the Windows equivalent of strace, with some filtering capability built-in. It also shows you the stack involved with a particular event, which can be useful for diagnosing the otherwise black box that is Windows. Eg [1]
The "filtering capability" actually makes up a good half of its worth. Being able to very quickly drill down to an annotated call stack for a specific IRQ on a specific file is really handy.
IRQs are very low level and can't be traced by strace or procmon. both can easily log specific syscalls, e.g. strace -e. strace can't quite filter on ioctl, but apparently procmon can't trace ioctl at all: https://stackoverflow.com/questions/9947933/how-to-log-the-d..., so strace is ahead there.
That strace can do it too is fine and all, but the Windows ProcMon collects a trace that you can then filter, like Wireshark. So it enables a workflow where you have no idea what's going on, collect a trace, and discover what entry to focus on and what paths to filter for. (This is what I demonstrated in the msys issue link I posted.)
An equivalent workflow is possible with strace too of course; pipe `strace` to a file and then discover what paths you want to grep for. It does become a bit noisy when the stack of every syscall is included, and requires more complicated grepping because it spans multiple lines, so you might have to first pre-process it into something structured like JSON.
Original ProcMon used ETW, Event Tracing for Windows; the analogous technology (although very different in style) on Linux is eBPF so that’s what this tool uses.
Sorry, it's been over a decade now and I still have nightmares sometimes. But yeah procmon is cool.