Hi,
I was going over some logs for an incident and noticed that a lot of logs we’re seeing are similar to the ones report here: Channel not found would be suppressed ( [Winlogbeat] Suppress excessive channel not found warning messages · Issue #35314 · elastic/beats · GitHub ). Has anyone else experienced the same?
NickFritts
February 19, 2026, 11:59pm
2
My team is responsible for that. It sounded like a regression and I poked around briefly and still thought it was. I asked a robot and it agreed. We’ll take a look
opened 11:56PM - 19 Feb 26 UTC
Winlogbeat
Team:Security-Windows Platform
# [Winlogbeat] Regression: "channel not found" warning log suppression lost in r… unner.go refactor
## Summary
The fix from #35317 that suppressed repeated "channel not found" warning messages was inadvertently dropped during the runner extraction refactor in #42736. Starting with 8.19.0, winlogbeat (and the filebeat winlog input) will log `WARN` or `ERROR` level messages **on every retry** when a configured channel is not found, rather than demoting to `DEBUG` after the first occurrence.
This was reported on Discuss: [It looks like winlogbeat (8.19.10) is showing noisy warn logs again](https://discuss.elastic.co/t/it-looks-like-winlogbeat-8-19-10-is-showing-noisy-warn-logs-again/385125)
## Background
Issue #35314 described the problem: if a configured Windows Event Log channel doesn't exist on the system (e.g. `Microsoft-Windows-Sysmon/Operational`), winlogbeat spams the logs with repeated `WARN`-level messages every 5 seconds.
[PR #35317](https://github.com/elastic/beats/pull/35317) fixed this by adding a `channelNotFoundErrDetected` flag that demotes subsequent occurrences to `DEBUG`:
```go
// Flag used to detect repeat "channel not found" errors, eliminating log spam.
channelNotFoundErrDetected := false
// ...
case !api.IsFile() && eventlog.IsChannelNotFound(err):
if !channelNotFoundErrDetected {
e.log.Warnw("Open() encountered channel not found error. Trying again...", ...)
} else {
e.log.Debugw("Open() encountered channel not found error. Trying again...", ...)
}
channelNotFoundErrDetected = true
```
([Original fix: eventlogger.go lines 134–159](https://github.com/elastic/beats/blob/7e3bd7c49a780af874fc0fd3ec02c017d59f43bc/winlogbeat/beater/eventlogger.go#L134-L159))
## How the regression happened
[PR #42736](https://github.com/elastic/beats/pull/42736) (backported to 8.19 as [#42842](https://github.com/elastic/beats/pull/42842), merged 2025-02-21) extracted the event loop from `eventlogger.go` into a new shared [`winlogbeat/eventlog/runner.go`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/runner.go). The `channelNotFoundErrDetected` flag was **not carried over** to the new code.
## Current behavior (8.19.x)
In [`runner.go`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/runner.go#L61-L72), the open-error handler logs at `WARN` or `ERROR` on **every** retry with no suppression:
```go
openErrHandler := newExponentialLimitedBackoff(log, 5*time.Second, time.Minute, func(err error) bool {
if mustIgnoreError(err, api) {
log.Warnw("ignoring open error", "error", err, "channel", api.Channel()) // WARN every time
return true
}
if IsRecoverable(err, api.IsFile()) {
reporter.UpdateStatus(status.Degraded, ...)
log.Errorw("encountered recoverable error when opening Windows Event Log", "error", err) // ERROR every time
return true
}
return false
})
```
`ERROR_EVT_CHANNEL_NOT_FOUND` matches both paths depending on [`IgnoreMissingChannel()`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/errors_windows.go#L43-L44):
- **With `ignore_older` / ignore missing channel**: hits [`mustIgnoreError()`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/errors_windows.go#L43-L44) → `WARN` on every retry
- **Without**: hits [`IsRecoverable()`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/errors_windows.go#L32-L41) (channel-not-found [is in the recoverable list](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/errors_windows.go#L40)) → `ERROR` on every retry
The [`exponentialLimitedBackoff`](https://github.com/elastic/beats/blob/d38bb52953baada39f9f12e199557d20e8334607/winlogbeat/eventlog/runner.go#L150-L186) slows the retry cadence from 5s up to 60s, but the log level never drops — users see a `WARN` or `ERROR` line every 60 seconds indefinitely.
## Expected behavior
Match the pre-refactor behavior:
1. **First** "channel not found" occurrence: log at `WARN`
2. **Subsequent** occurrences: log at `DEBUG` (effectively silent at default log level)
3. If the channel becomes available (Open succeeds): reset the flag so the next failure logs at `WARN` again
## Suggested fix
Add a flag (or counter) to the backoff condition closure or the `exponentialLimitedBackoff` struct so that after the first channel-not-found log, subsequent retries for the same error are demoted to `DEBUG`. The existing `reset()` method (called when the error condition clears) is a natural place to reset the flag.
## Versions affected
- 8.19.0 through at least 8.19.10 (when PR #42842 was included)
- Likely also affects main / 9.x if `runner.go` has the same pattern there
## References
- Original issue: #35314
- Original fix: #35317
- Refactor that dropped the fix: #42736 (8.19 backport: #42842)
- Discuss report: https://discuss.elastic.co/t/it-looks-like-winlogbeat-8-19-10-is-showing-noisy-warn-logs-again/385125
Great thank you! I saw that the github issue was closed. Do you know if the fix was included in 8.19.12?
I believe the fix was shipped with v8.19.12 , v9.2.6 , and v9.3.1 .
Awesome thank you so much for the quick turnaround on this!
