@androidi: ETW is not heavy weight necessarily, but if you ask it to do a lot it will use the hard drive a lot. In particular if you want stack traces, it does do what is called 'merging' which involves finding all the DLLs that were in the trace and getting the PDB signatures (so you can find the PDBS) from the DLLs. This does take 10s of sec and uses the hard drive. However if you collect just a little, then it is very light. This is independent of OS version.
@PerfectPhase: Your situation is complicated by the fact that you seem to wish your output to go to the windows event log (using channel attribute). This mechanism is 'old style' where a eventSource 'knows' where it is logging (a particular place (channel) in the windows event log). As you can see for complex situations, it is not as flexible as you would wish. Your situation however is complex enough that it does not make sense to discuss it in the comments. If you still care you can contact me at vancem@Microsoft.com and I can describe other options you have.
@Onurg: I don't properly understand your complaint, but something I did not talk about in the video is that EventSource can go to in-proc event listeners. Thus if you REALLY like the way log4Net works, you can frankly pipe all the data from your eventSource to whatever logging mechanism you would like to use. The advantage of this is that you can go to BOTH log4Net AND ETW (and frankly anywhere else), and code that does the logging does NOT KNOW what logging mechanism is used (thus you get dependency injection for 'free').
@MagicAndre1981: For what it is worth, the fact that stacks interfere with evnetSource decoding is a known bug in the WPA stack. They are working on a fix. You can use PerfView to work-around the problem in the short term. They should have a fix reasonably soon.