Iterating through Event Log Entry Collection, IndexOutOutOfBoundsException

in a service application I am iterating through the Windows application event log to parse Events in order react 开发者_JAVA技巧depanding on the entry message. In the case that the event log is full (Windows usually makes sure there is enough space by deleting old entries - this is configurable in the eventvwr.exe settings), the service always runs into an IndexOutOfBoundsException while iterating through the EventLog.Entries collection. No matter how I iterate (for-loop, using the collections enumerator, copying the collection into an array, ...), I can't seem to get rid of this ´bug´.

Currently, I ensure that the log is not full in order to keep the service running by regularly deleting the last few item by parsing the event log file and deleting the last few nodes (Don't beat me up, I couldn't find a better alternative...).

How can I iterate through the collection without trying to access already deleted entries?

Is there probably a more elegant method? I am only trying to acces the logs written during the last x seconds (even LINQ failed to select those when the log is full - same exception), could this help?

Thanks for any advice and hints

Frank

Edit: I forgot to mention that my assumption is the loops are accessing entries which are being deleted during iteration by Windows. Basically that is why I tried to clone the collection. Is there perhaps a way to lock the collection for a small amount of time for just my application?

---

I have hit this as well, more so on 2008R2 Domain Controllers. The problem is the logs are wrapping, and so the index seems to change between when you started iterating the events and when you got to this point.

Doesn't seem to be a cure other than retry.

---

Looking at it from a practical point of view, why is there a problem at all?

If you want to iterate over all the entries, and sometimes when you try to read an entry that doesn't really exist you get an IndexOutOfBoundsException, then just catch this exception and ignore it.

If you know what this exception means, and you know what you want to do, just handle the exception and continue working. That's what exceptions are for, after all...

---

In case anyone finds this thread:

Avoiding this behavior doesn't seem to be possible. Even copying the collection fails and locking the file is not possible (due to system restrictions). Instead, I implemented a periodic checking algorithm which backs up the event log and clears it at a defined usage percentage (e.g. 95%), such that an overflow or deletion should not happen.