Crashes occur while collecting from the ForwardedEvents channel

The environment includes source computers running Windows Server 2012 R2 or earlier forwarding to a newer collector

In environments where pre-Windows Server 2016 systems forward events to a newer collector host, the Log Collector process might become unresponsive while processing those forwarded events. A configuration option is available to prevent the crash, with a minor trade-off in message fidelity.

When the Collector processes a forwarded event, it needs to render the human-readable message text. Windows Server 2016 and later include a RenderingInfo XML element with each forwarded event, which carries a pre-formatted message the Collector can use directly; no further rendering is required on the collector host.

Earlier Windows versions do not include RenderingInfo. The Collector must instead render the message locally by calling FormatMessage() (EvtFormatMessage() in the winevt API) against publisher metadata on the collector host. Where the event template on the source system does not match the metadata available on the collector, this call can be unsafe and may crash the Collector process.

This behavior is documented in the Microsoft EvtFormatMessage reference, which notes that the publisher-metadata handle may be NULL for forwarded events precisely because RenderingInfo is expected to be present.

Set disableFormatMessage: true on the affected channel. This instructs the Collector to skip local message rendering entirely, eliminating the unsafe call.

sources:
  forwarded:
    type: wineventlog
    sink: logscale
    channels:
      - name: ForwardedEvents
        disableFormatMessage: true

Structured event fields are unaffected and collected in full. However, events forwarded from pre-Windows Server 2016 sources will not include a fully rendered human-readable message string. Events from Windows Server 2016 and later sources are unaffected, because their message is sourced from RenderingInfo rather than from FormatMessage()>.

The option defaults to false and can be set per channel.

There is no upstream fix for this issue. The disableFormatMessage workaround is the recommended long-term mitigation for environments that include legacy source systems. Upgrading source systems to Windows Server 2016 or later will also resolve the issue, because those systems include RenderingInfo in forwarded events.