Event Logs

At the end of the day, Event Logs are what WEC is all about on both sides of the WEC process: source and destination.  Windows event logs are more than a simple, discreet text file.  The actual file representing the event log is only directly accessed via the Windows Event Logging service.  Event logs will not grow beyond the maximum size defined for each log via Event Viewer, group policy or Intune.  Depending on the log’s retention settings, when the log reaches maximum size, as new events are logged, Windows either

  • Overwrites the oldest events as needed
  • Archives the log.  Windows closes the file, renames it and opens a new file for new events.  This does ensure no events are lost but 1) WEC does not forward events from archived logs and 2) archived event logs will continue to build until the volume fills up or you implement a process to delete archived event logs.  The problem with this feature is that it is very I/O inefficient.  Windows does not simply cut the current file free, renaming it to an archive and begin writing to a new file.  Instead, it creates an empty archive and writes the old events out to it.  Worse, you cannot specify a different path for archived files – meaning both the reading and writing I/O have to be handled by the same “spindle”.
  • Windows itself crashes with a blue screen stop code of C0000244 {Audit Failed}.  This extreme behavior is only enabled if the security option “Audit: Shut down system immediately if unable to log security audits” is enabled in group policy and the log is configured as Do Not Overwrite Events or Overwrite Events by Days. 

It’s important to avoid lost events on both forwarders and collectors.  On forwarders the goal is to forward source events before they are overwritten.  This is accomplished by specifying a maximum log size sufficient to save up events to cover any expected / required outage and to keep collectors and the network between forwarders and collectors as healthy as possible.  On collectors the goal is to get events out of destination logs and into your SIEM or other downstream consumers before being overwritten in the destination log.  Configure the destination log’s maximum size large enough to save up events to cover the maximum amount of time required to survive outages of downstream consumers and the amount of time it will take them to catch up.  You need to monitor the ingestion rate as reported by your SIEM and confirm that it meets or exceeds the incoming WEC rate of events to your collector.  To make sure your SIEM is utilizing multiple streams of consumption, you may need to implement multiple destination logs instead of trying to push all the events through the Forwarded Events log on each collector.

Source Event Logs

Each subscription can pull from multiple source logs.  The collector maintains a registry key for each forwarder (aka source computer) where, among other things, it stores a “bookmark” for each source log for that forwarder.  This is how WEC keeps track of the most recent forwarded event for each source log on each source computer.  The bookmark is basically a forward only record count that is immune to log wrapping or clearing.  On the forwarder, the NETWORK SERVICE special principal needs Read access to any source event log from which it collects events; this is only an issue with the Security log.

Destination Event Logs

Each subscription has one and only one destination log.  Multiple subscriptions can point to the same destination log.  We recommend creating additional custom destination logs rather than funneling everything to Forwarded Events. 

Using multiple destination logs is important for a number of reasons.  By co-mingling events from multiple subscriptions in one destination log you cannot determine how many or which individual events are being selected by different subscriptions and their xpath queries.  Furthermore, some downstream consumers, like SIEM agents, have an upward limit on EPS.  If your total incoming EPS to the collector exceeds your agent’s capacity, events that made it to the collector will cycle out of the destination log before being consumed by your SIEM.  By utilizing multiple destination logs, most agents will spin up a separate thread for each log and be able to do parallel processing. 

But creating a custom event log that WEC will actually use as a destination requires special steps. 

Creating Custom Event Logs for WEC Destinations

Simply using New-EventLog will create the log – but WEC will not allow you to use it as a destination.  Instead, you must

  1. Create an event log manifest (.man)  file
  2. Compile the manifest using mc.exe to a .rc file
  3. Compile the .rc file using rc.exe  to a resource (.res) file
  4. Compile the resource file into a DLL using csc.exe
  5. Install the manifest and DLL using wevtutil.exe

How Supercharger helps with Event Logs

One of our best features regarding event logs is how easy we make it for you to create custom event logs - even on multiple collectors.

Supercharger also monitors each destination log on each controller and detects problems like stalled event logs. We capture hourly statistics about incoming events as well as log continuity tracers so that you can make sure events are flowing uninterrupted and at the expected rate. We include special features for helping to get assurance that your SIEM is keeping up with the inflow and not dropping events.


Manage, Scale and Heal Windows Event Collection with Supercharger
DownloadEnterprise PricingAsk Sales