Reputation:
I have a humble VB.Net forms app with a listener for the Windows security log. It's configured such that whenever a network login succeeds or fails (Event ID 4624/5, Logon Type 3), it records the associated source IP and username used to log in, printing these (with the program's own timestamp) to my output log form.
It works great - until, for no reason that I can clearly ascertain, the program suddenly reads my entire Windows Security log and dumps every single "matching" event that has ever happened into the form – which promptly crashes the program (freezes it actually, but I kill it first... it takes a loooong time to finish when this happens).
Now, upon examining the output one such occurrence, the timestamps DON'T match the actual event log. They start at the time that the program "panics" and reads the entire log from beginning to end. So an event that happened two days ago has a timestamp from today in the program, because that's when the program "read" the data.
But, how in the world is this happening when the EntryWritten
event should only be raised when each event is actually added? It's like every single entry in the log is suddenly a "New Entry" all over again. This seems to only occur on my Windows 10 PC, and NOT on my Windows Server 2019 machine.
Possible trigger (or at least synchronous) events have included:
I'm totally lost here; I don't even know if this is a Stack Overflow question or a Super User question... but since cross-posting is frowned upon, I'll start here. Also worth noting, no new event is even added when this happens. It stops at exactly where the log was at when the flood started; actually new events that occur after the flood begins do not seem to get included in the flood. (I may be wrong about this, but I don't have a reliable way of checking - the above methods are not repeatable, unfortunately.)
Update: I can with 100% reliability induce the "Event Recall Flood" by repeatedly failing an RDP login from the machine in question to another machine. Not sure why this is causing every event in the Security log to fire the EntryWritten
event though...
Upvotes: 2
Views: 146
Reputation:
The Security event log (probably the others as well) in Windows 10 (Ver. 1909 Build 18363.778) will "reprocess" the entire log when it hits capacity and is trimmed, causing all remaining events in the log to display themselves as "new events" to any attached EventLog
listeners, resulting in a flood of EventWritten
triggers that will hang an application if the log is sizable. (Min. size is 20Mb as of this writing, about ~31,000 events... so yeah.)
This effect can be curtailed: (1) temporarily, by emptying the log; or (2) more permanently, by configuring the log to "Archive the log when full, do not overwrite events
."
Huge thank you to Andrew Morton for the spot-on tips on where to look! As he mentioned in his comments, this "seems like a bug." It has now been reported to Microsoft Feedback Hub with documentation.
Upvotes: 2