To all the commenters lamenting the lack of filtering capabilities, I would like to remind that this is a console program, which in the spirit of Unix should "do one thing and do it well."
If you need filtering, sorting, correlating, and so on, you should add pipes after this program. I believe Powershell pipes are even more powerful than plain text ones, although I haven't used them myself.
grep's good for sure but the comment you are replying to is a reply in turn to someone speaking specifically about powershell piping capabilities. personally i am a unix person, not a windows person, but i believe that for a tool to be most effective it should adhere to the workflow of the platform it is written for. since wtrace is written for windows it makes sense to expect that it should integrate well with the windows way of doing things.
The reason the filtering needs to be in the tool, not the shell, is performance. strace hooks into every syscall made by the application, and it generates a bunch of IO, which affects the performance of the traced application badly.
At the risk of stating the obvious - tracing in itself is not that useful, unless you are after just the aggregated stats. To use traces for reversing the API/IOCTLs, it's equally (if not more) important to have a good UI for filtering, analysis and cross-correlation.
There's another tool that fills this particular niche quite well [1] and having used it to reverse HP Smart Array drivers among other things I can't recommend it highly enough.
Took a look at the API Monitor app you recommended -- it is interesting -- can it be used as a procmon replacement in your experience? The UI seems to be a bit better (more intuitively) organized...with procmon, between one instance of running it and another, I always have to search for where the menu settings are to do some action -- it's almost like a GUI over a command line program.
This is one of the greatest tools for dealing with ETW. And it is a great way to introduce people to ETW as well, before diving into the arcane commands necessary to drive it yourself from the command line.
Yeah, but it's limited because process monitor stores its output in memory (from what I can see) even though if you use a backing file other than the swap file.
I use this tool all the time!
I really wish there was a command line version that is divorced from the GUI that you can pipe to another process or file. This might be as close as any I've found so far!
I use procmon heavily too. Good point about the mem usage. I find procmon especially helpful for diagnosing COM activation issues; being able to trace all the registry and file system accesses is invaluable in figuring why a specific DLL is or isn't loaded.
No idea on procmon refusing to load as Admin. But I would caution on using the System account to run services that use COM activation, which does ClassId & ProgId lookups via the HKCU hive. LocalSystem will go to HKCU\.Default [1], which is probably not what you need.
Me too - I usually start my diagnostics session with Procmon. Not so long ago, Mark Russinovich revealed that they are working on a command line version of Procmon for Nano server (https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-16...). I hope they will release it soon :)
Very nice! I really enjoy developing on Windows but whenever I read a blog post about someone on *nix hunting down a problem with strace I've felt a bit limited. I know Windows has similar instrumentation but it felt a bit inaccessible to me.
This looks perfect! Simplest imaginable interface, the output I'd need. Great work!
Ah, this will be great. I do miss the ease of using strace to hunt bugs. Even just being able to find out where a program is looking for a file it can't find or a network connection that doesn't work is useful.
The executable can be found on the release page [1]. I don't know any Windows ports of ltrace, ktrace, or dtrace. But you may have a look at the list of ETW events [2] supported by the Windows kernel and you should find the ones you need for your diagnosis. With each version of Windows the list of event providers for different parts of the system is also growing (you may use 'logman query providers' to list them).
This tool is not supposed to compete with ProcMon, which I consider the best tool of the trade. But... currently ProcMon can't be run on Nano Server (thus for instance on Docker). ProcMon does not trace RPC/ALPC requests either. I even suggest in the wiki that you may pipe the output of wtrace to ProcMon (I wrote a simple tool send2procmon [1] for this purpose): wtrace notepad | select-string "Rpc.*Call" | send2procmon
If you need filtering, sorting, correlating, and so on, you should add pipes after this program. I believe Powershell pipes are even more powerful than plain text ones, although I haven't used them myself.