Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
Sorry, it's been over a decade now and I still have nightmares sometimes. But yeah procmon is cool.
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.
[1]: https://github.com/msys2/MSYS2-packages/issues/138#issuecomm...
strace -k
> specific IRQ
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.
> specific file
strace -P path
>strace -k
>> specific file
>strace -P path
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.
This file says it does, though only for network events: https://documentation.help/Process-Monitor/documentation.pdf