3 ms·
> 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
by CurtHagenlocher 10y ago
> 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.)
- ksk 10y agoI know what ETW is and how it works. I don't know what your point is, sorry.
- nitrogen 10y agoSometimes conversations are less like arrows and more like trees -- few points, lots of branches.
- rixed 10y agoI think his point was: you really should read about dtrace, esp. how to instrument user programs (without instrumentation).
- ksk 10y agoErr, 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?