>> Lots of things inside Windows emit ETW events, which is Windows equivalent of DTrace
It'd be less wrong to say "like Windows equivalent of syslog".
ETW is nowhere near as sophisticated as DTrace. ETW is more or less a simple logging subsystem, it's not actually modifying any code in memory to dynamically (that's what that D is for) insert instrumentation.
So if something is not compiled to emit ETW events, ETW can't trace it at all.
DTrace can trace anything that runs on the system. No need for binaries to emit any events.
> it's not actually modifying any code in memory to dynamically (that's what that D is for) insert instrumentation.
First of all, it is impossible to instrument a random binary on the fly without private symbols. Even otherwise, DTrace requires instrumentation to be inserted in user code. Without it, it will only get data from built in probes in the OS libraries/kernel/etc. (Same as ETW)
>So if something is not compiled to emit ETW events, ETW can't trace it at all.
This is false. I don't know if you've ever used ETW but I use it regularly to run traces on binaries that don't have any ETW specific instrumentation.
> First of all, it is impossible to instrument a random binary on the fly without private symbols.
That's not true. You can use DTrace instrumentation on any binaries. It's more effort, of course, to figure out what address is what. You can work backwards from system calls to get some reference point about target process data structures. And of course trace obvious things such as function entry points, particular instructions, etc.
Also other dynamic binary tracing frameworks can do tracing without symbols.
I don't think you get it. Getting the address of the function call and capturing the entire call stack of a running process is trivial. It has been possible to do this for decades on all platforms where the ABI is known. Knowing what address belongs to which function, knowing the type of the parameters, return values, etc, requires a ton of effort. But I could be wrong. Can you point to any common usecase of dtrace where people use it when no debugging symbols and no providers are present in the user code and everything has to be reverse engineered? I'm not going to bother with inlined functions and the like - which would be unfair for any tool to automatically know about.
> I use it regularly to run traces on binaries that don't have any ETW specific instrumentation.
Then those binaries are making use of other binaries which do emit ETW events -- including, possibly, binaries that ship with Windows itself. ETW is basically a pub-sub system. If there isn't code that explicitly sends an event, then there's no event. (And if there aren't currently any listeners subscribed, then the cost of emitting the event is pretty small.)
Err, if you already know the memory map of the functions inside a process image, then understanding the call stacks is trivial for any debugging or performance tool - on any platform. This does not require any instrumentation. And if you're reverse engineering, then dtrace is the wrong tool anyway. So, can _you_ point to any common use case of dtrace where the probes aren't already present in the kernel/libs/user code?
It'd be less wrong to say "like Windows equivalent of syslog".
ETW is nowhere near as sophisticated as DTrace. ETW is more or less a simple logging subsystem, it's not actually modifying any code in memory to dynamically (that's what that D is for) insert instrumentation.
So if something is not compiled to emit ETW events, ETW can't trace it at all.
DTrace can trace anything that runs on the system. No need for binaries to emit any events.