Http://blogs.msdn.com/ B /ryanmy/archive/2005/05/27/422772.aspx
-
- Uniformity. If you're debugging systemic problems involving multiple components, and all the involved components use ETW, you can have them all deliver their information to a single log file with uniform, steady timestamps, and write a single application that parses them all.
- Speed. ETW is extremely fast for providers to use, since all the I/O is handled by the kernel instead of by your module. It typically takesOnly 1500-2000 cycles, Depending on settings, to deliver an event and return to your code. One can easily deliver thousands of events per second even on login ent machines. We 've achieved20,000 events per second while only using 5% CPU load on a P3 500 MHz!(Yes, We have machines that old in our perf testing labs -- not everyone who uses Longhorn will be using a modern machine !)
-
- (On my machine, each log time is about 15 ~ 20 microseconds intel duel CPU e2220, 2.4 GHz)
- Consistency. With fprintf () or other homebrew systems, logging tends to be very slow and intrusive and is thus usually compiled in. with ETW, logging is extremely fast; furthermore, since logging is turned on by a controller and is usually off by default, you can actually leave the ETW events in final Shipping Code! If problems are found in the field, send the tester an app that starts a trace and turns on the provider, then read it later. Vendor, component components in Longhorn will ship as ETW providers.
-
- Reliability. ETW isn't a new thing -- it's actually been in the OS and actively used since Win2k, and has been constantly refined since then. furthermore, ETW is available in both user-mode apps and kernel components. (The latter access it through a mj_system_control IRP .) this leads...
- OS cooperation. The Windows kernel can provide into highly useful events via ETW for diagnosing performance problems. Find out when and where disk I/OS, registry accesses, hard faults, and other performance problems happen! More on this later...
