I have what seems to be a small issue with a monitor I have set up. I set up a monitor to watch the event viewer for event ID 7, indicating a bad block on the hard drive. The issue I seem to be running into, is that after it catches the error, and a chkdsk is initiated, through auto remediation, it catches the same vent, unless I go in and clear the event log on the ones that I could find the ID in. On many of them, I can’t seem to find the event ID 7, but the alert trips. On most, after I clear event log, the error does not return.
Hi @BOSS
I’ve created a ticket regarding your issue. Our team will be in contact with you.
Thank you;
Serhat Ince
Thanks, I am keeping an eye on the situation, and will update if I see anything else with it.
I got to digging down on one of my systems that keeps popping an event ID 55, normally a corrupt filesystem error, well it would seem that event 55 is some strange kernel power event on this windows 10 system?? Is there anyway to make it just look in a certain log file, mainly the one I would want to look in is the administrative events. I am going to have to disable all my event log monitors, and regroup, and come up with another strategy to get the results I need to properly monitor my clients systems. I can tell you that out of the hundreds of errors I received from these monitors, only one really had a bad block on the hard drive, this seems to me to be some really bad odds.
I was thinking, would it be possible to also be able to que other fields for the event viewer monitor?? I seemed to be getting many false positives, but some may be that there are different things that kick off the same event ID, but it would allow for fewer, if no false positives, if this was possible. There are several fields in each event, like log name, source, ID, level, user, category, keywords, date and time logged, and maybe more. If we had the option to set a variety of complexity, we may be able to eliminate many false positives that we may be seeing??? Any other thoughts on this???
I see that it is possible to check the source already, I think that as I am getting more familiar with the software, I am able to come up with some very creative ways to work around certain issues I was having. I think that I just may be able to pull off exactly what I expect with what is available, since the new procedure @mkannan wrote with getting the SMART status.
Great to hear, We can always help you with any script needs you might have. Just share the idea 
After digging deeper into this issue, I feel that the issue was in my competence, not with C1. The 3 conditions we can set in the event section can ensure that there is very little room for false positives.
I’m having the same issue: I’ve created a monitor with a condition checking for Event ID = 7; this gets tripped on a computer that doesn’t have any events with Event ID 7. Also, I tried setting all three of the selectors with the Event ID condition (Event ID, Error Level, and Source), but only the last selector that I enter is actually saved when I update and save the condition.
Please ensure you set it to trip only if all conditions are met, not any. And the source should be disk not the event ID
@slr
Are you still experiencing the same issue after changing the Monitoring Settings according to @BOSS suggestions? If yes, kindly send us a screenshot of the Monitoring Settings you have and the result at c1-support@comodo.com to further investigate this issue. You can also refer to this link for more information on Monitoring Settings : https://help.comodo.com/topic-399-1-786-10984-Monitoring-Settings.html
You are very welcome, we are all trying to get to the same place, I am glad we could of been of some assistance to you!!!