Infinite loop in EventLogWatcher class

[KuznetsovDenis]

Description

In the RequestEvents method of the EventLogWatcher class, an infinite loop may occur. This can happen if the NativeWrapper.EvtNext call returns true on the first attempt, indicating that not all log entries have been read. If an exception occurs during the next iteration of the loop, for example, due to the remote computer disconnecting from the network, the result variable will never be reset to false, leading to an infinite loop.

Reproduction Steps

This issue is challenging to describe concisely, as reproducing it depends on an exception occurring when connecting to a remote computer. In general terms, the scenario looks like this:

using System.Diagnostics.Eventing.Reader;
...

EventLogSession session = new EventLogSession("remote-pc");
EventLogQuery query = new EventLogQuery("Application", PathType.LogName) { Session = session };
EventLogWatcher watcher = new EventLogWatcher(query, null, true);
watcher.EventRecordWritten += (s, e) => { 
    if (e.EventException != null) {
        logger.LogError(e.EventException, "Error occurs on an attempt to read log");
    } else if (e.EventRecord is EventLogRecord record) {
        logger.LogInformation("Log entry has been read");
    }
};
watcher.Enabled = true;

After enabling the watcher, but before all log entries have been read, the remote computer (remote-pc) must disconnect from the network. This triggers an infinite loop.

Expected behavior

After an exception occurs, I expect the watcher to either wait for the computer to reconnect to the network or simply transition to a disabled state.

Actual behavior

The EventRecordWritten event handler triggers an infinite number of times, causing the program to hang.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-eventlog
See info in area-owners.md if you want to be subscribed.

[ericstj]

This behavior has been present forever - here in .NETFramework https://referencesource.microsoft.com/#System.Core/System/Diagnostics/Eventing/Reader/EventLogWatcher.cs,212

Looks to me like this reports the error through EventRecordWrittenEventArgs https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventing.reader.eventrecordwritteneventargs.eventexception?view=windowsdesktop-9.0#system-diagnostics-eventing-reader-eventrecordwritteneventargs-eventexception

It seems to me this type is meant to be a long lived type that watches for events as long as Enabled is set - IOW it's an infinite loop by design. I can see why it's expected that it would surface these exceptions through the callback, since there is no user code directly calling RequestEvents.

Any reason you can't just subscribe to that handler and if you see an exception that you don't like, then set Enabled to false and surface this through your application?

Looks to me like either setting Enabled to false or calling Dispose() will terminate this loop.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.