windows_event_log: source subscribes successfully but delivers zero events when read_existing_events is false

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

With read_existing_events left at its default (false), the windows_event_log source subscribes to every channel successfully and then delivers zero events, indefinitely — while new matching events are demonstrably being written to those channels.

There is no error, no warning, and no checkpoint file. The source logs Pull-mode subscription created successfully and Starting Windows Event Log source (pull mode) and then goes silent. From the outside the shipper looks perfectly healthy.

This is the dangerous part: a fleet-wide rollout would pass every health check and still ship nothing.

Setting read_existing_events = true makes the same source work immediately.

Configuration

Failing (default read_existing_events):

data_dir = "C:\\ProgramData\\vector"

[sources.win_security]
type = "windows_event_log"
channels = ["Security"]
event_query = "*[System[(EventID=4624 or EventID=4625)]]"

[sinks.graylog]
type = "socket"
inputs = ["win_security"]
address = "10.0.0.2:12201"
mode = "udp"
encoding.codec = "gelf"

Working — identical source, one flag added:

data_dir = "C:\\ProgramData\\vector-test"

[sources.sec]
type = "windows_event_log"
channels = ["Security"]
only_event_ids = [4624]
read_existing_events = true
max_event_age_secs = 1800

[sinks.out]
type = "console"
inputs = ["sec"]
encoding.codec = "json"

Steps to reproduce

1. On a domain-joined Windows client, run the first config.
2. Generate matching events (e.g. repeated WinRM/RDP logons produce 4624).
3. Wait 10+ minutes. Observe: no events at the sink, no windows_event_log_checkpoints.json anywhere under data_dir, and no ERROR/WARN in the Vector log.
4. Run the second config. Events appear within seconds.

Observed behaviour

• ~10 minutes with the default: 0 events, no checkpoint files created, log contains only the successful subscription lines.
• Same host, same channel, read_existing_events = true: 115 events in 40 seconds, checkpoint file written.
• Cross-check: NXLog-CE was running on the same host against the same channel throughout and shipped the 4624 events during the exact window in which Vector delivered nothing — so the events unquestionably existed.

To rule out the sink, the working run used a console sink and a separate data_dir. The absence of any checkpoint file in the failing run indicates the source never read anything, i.e. the problem is upstream of the sink.

Expected behaviour

With read_existing_events = false, the source should deliver events that occur after subscription. Delivering nothing at all — silently, without an error and without ever checkpointing — should not be a reachable state.

If there is a legitimate reason the pull loop cannot pick up new events in this mode, it should at minimum log a warning rather than appear healthy.

Configuration / environment

• Vector version: vector 0.57.0 (x86_64-pc-windows-msvc 8832452 2026-07-14 20:58:30.491174540), MSI install
• OS: Windows 10/11 client VM, domain-joined, German locale, running under SYSTEM
• Channels tested: Security, Application, System, Microsoft-Windows-Dhcp-Client/Operational, Microsoft-Windows-Dhcp-Client/Admin — none produced events or checkpoints with the default

Additional context

This may be related to #25194 (source freezing after idle, marked fixed) and #26115 (no re-subscribe on ERROR_EVT_QUERY_RESULT_STALE) — all three share the shape subscription looks fine, ingestion silently stops or never starts, no self-recovery. I did not see this specific "never starts at all" variant reported, hence the separate issue.

Two smaller things noticed while getting this working, mentioned in case they are useful — happy to file separately if preferred:

1. only_event_ids with 26 IDs fails at startup with ERROR_EVT_INVALID_QUERY (0x80073A99). This is the Windows limit of 20 expressions per XPath query rather than a Vector bug, but the resulting message is hard to act on. Using ranges in event_query works around it.
2. The gelf codec rejects the source's own output until it is reshaped: event_data (map), keyword_names (array), level (GELF expects an integer, the source emits a locale-dependent string such as Fehler/Error) and version (GELF reserves it as a string, the source emits the Windows event version as a number). Each rejection drops every event at the sink while the source keeps running.

Start with the windows_event_log source's pull-mode subscription and the read_existing_events=false path, then reproduce the failing configuration on Windows using the Security channel and console sink. Trace why new matching events are not read or checkpointed; done means post-subscription events are delivered and the source does not remain silently healthy when ingestion fails.