Feature Requests (post your ideas here) RRS feed

  • General discussion

  • We are very serious about your ideas on how to improve Event Tracing for Windows and the Windows Event Log.  Please use this post to add your feature requests and ideas for how you'd like to improve future releases.
    Thursday, April 30, 2009 6:12 PM

All replies

  • Hey Kevin,

    This might be the wrong avenue for this, but my question about auditing Security Event ID 4625 on a Server '08 Datacenter box might have some bearing on thread anyways. Please move or delete this if necessary.

    I basically cover two things below:

    1) My current problem with Windows Event Log
    2) Feelings about access to data and tools dealing with Windows Event Log and ETW


    If I am not just misinformed (fully possible), the event log (Windows Event Log) is not capturing all the flavors of mstsc's IPAddress data XML element correctly as ETW does its processing. Windows 2003 and XP boxes haven't been a problem -- they display their IPs seemingly every time. 2008 boxes audit failing rdp connections against the server I am running my program (pure C# using System.Diagnostics.Eventing.Reader) on never seem to log the IP address element.

    Is this due to some negotiation difference?

    Big problem for me, because I'm trying to implement a relatively quick IP blacklist solution based on 529/4625 security ID hits, while keeping the codebase as extensible (and managed) as possible.


    I've had to dig through the ETW resources recently, and I must admit -- it's out there -- but I suppose it could be easier to find, for one. If I can't deal with my issue through Windows Event Log, hopefully it can be done with ETW.

    It isn't quite a signal-to-noise problem -- more like signal-to-signal. MSDN and Technet and Social MSDN have information everywhere, but step-by-step tutorials feel lacking. Integration among the three certainly is.

    I (and I hope others) would LOVE some logman.exe and such tools with basic GUIs for simple things, like determining whether common events are being raised, or simulating their activation (like consume.exe except for events). Simple GUIs can break people into branches of technologies they never even considered before. I'm a system administrator for Windows, and I was TOTALLY ignorant of the advantages (some necessities, and occasionally disadvantages) of using WMI to accomplish different tasks, be it in scripting (vbscript or PowerShell), coding (C#), or in some combination.

    For instance, the wbemtest tool helped me understand WMI FAR better than before (which has been great for the new PowerShell 2 stuff with System.Management.Automation.PowerShell). And there is barely any technet coverage on wbemtest, and no MSDN coverage.

    Granted, there is always the managed/unmanaged divide, but are there any equivalent stepping stones for ETW? If not, can any of that be in the future for ETW? Or do I just need to bite into the latest SDK? =P

    Truly, thanks for all the tools, code samples, etc so far -- but it seems to be an ENORMOUS area of possibility for developers, hardware manufacturers, and Windows-oriented service companies, and one that unfortunately can be quite difficult to navigate.


    Sunday, November 15, 2009 11:16 PM
  • Kevin,

    We are working to add WPP tracing to our drivers and are almost finished.  But, we have found that the tools for viewing and parsing are VERY limited.  Specifically we have used TraceView and NetMon.  Both of these applications do not allow for a simple search/find.  This is the most important thing when viewing/analyzing a log.

    Are there any other 3rd party viewers you could recommend??


    Friday, March 26, 2010 8:31 PM
  • We have been using Windows Event Collector service in a number of configurations. Our biggest complaint is the universal lack of detail in error logging. Debugging an issue can be very difficult. 

    Tuesday, June 28, 2011 6:00 PM