Jump to content

Recommended Posts

Posted

I use the Scheduler of EIS to run a scan on every Monday at 18:00. This works fine if the system is up and running at the scheduled time. If that is not the case, then the Scheduler completely ignores that I selected the "As soon as possible" option. The scan isn't executed at all.

 

This week I tried something similar on another pc, but now I scheduled a daily scan at 18:00, although I know that this pc is almost never up and running at 18:00. On this second pc I get the same result: the Scheduler ignores that I selected the "As soon as possible" option.

 

Is it normal that the Scheduler ignores the "As soon as possible" option?

  • Administrators
Posted

As soon as possible means the next time ekrn.exe starts, ie. typically when you turn on or restart the computer.

Posted

EIS ver. 12.0.31

I noticed something similar after my recent upgrade to Win 10 1809.

When I was running 1803, I had the PC set to never enter standby mode. This was because my old hardware was not compatible with it if Core Isolation/Memory Integrity was enabled. I reenabled standby mode on 1809 since it won't let me enable Memory Integrity.

My scheduled scan is set to run on Thursday at noon. Yesterday the scan did not run and the PC was in standby mode at that time. I also have the run as soon as possible if scan is missed option enabled. So I have now set it to run if does not do so after 4 hours from the scheduled time.  So we'll wait and see what happens when the PC happens to be in sleep mode at scheduled scan time.

Posted (edited)
13 hours ago, Marcos said:

As soon as possible means the next time ekrn.exe starts, ie. typically when you turn on or restart the computer.

Well, that is exactly what I expect from this option, but it doesn't work that way in EIS 12.0.31.0, neither on WIndows 7 nor on Windows 10. The Scheduler simply doesn't care about missed tasks, but that is nothing new.  When I started using the Scheduler years ago in ESS 7.0.302.26 on Windows 7, the "As soon as possible" option already didn't work.

Could it be of influence that both EIS (and previously ESS) and Windows are Dutch versions or that the user who turns on the PC after a missed task doesn't have administrator rights?

Edited by AGH1965
Posted
4 hours ago, AGH1965 said:

or that the user who turns on the PC after a missed task doesn't have administrator rights?

I run as a limited admin and never created a standard user account, so that is not the culprit.

Posted

I tried using the option "Immediately, if the time since the last run exceeds a specified value" with "Time since last run" set to 1 hour. Also with this option selected the Scheduler keeps ignoring missed scans.

  • 2 weeks later...
Posted

It is more than a week later now. The scheduler is still configured to perform a dayly scan at 18:00 and if that scan was missed, then it shall be done immediately if the time since the last run exceeds more than 1 hour. Each day the PC has been used for several hours, but never at 18:00. The result of this all is that the scheduler didn't run any scan at all. Tools > More tools > Log files confirms this.

It would be nice if ESET would fix the scheduler, because what is the use of a scheduler if you have to remember yourself to turn on the PC on a certain time?

 

Posted (edited)

Since you're not getting anywhere, and this is pure SWAG logic .....  is there away you could let it Run a Scan by Schedule at 1800 on a Monday and set the "Recovery if missed " for - Immediately if last run exceeds 24 hours / Not 1 (as shown in K-Base example for a weekly Friday scan). Make sure it's asleep at 1800 the next Monday and then wake it up anytime after & see what happens.  Maybe there is some quirk in the coding logic that wants the "Exceeds #" for Last Run (on a Missed Scan) to be 24 hours (24 Hours + 1 second would be required to MISS a Daily Scan) Vs 1.

This Schedule logic contradiction thing is a wide-spread issue. The MBAM Setup screen can show - Recover if Missed by 1 hour - ( implies IF the computer wakes up at "8:00:01 or after" Following a Missed 07:00:00 Scheduled Scan, then Scan.) But 2 Clk's backing out to the Review Screen shows - "Run again Within 1 Hour of Last Miss (implies 07:00:00 asleep / IF the unit awakes between 7:00:01 and 8:00:01 Run the scan. If it doesn't, then DON'T Scan. HOW is that for clear Recover logic?

Hope the above works. Nothing to lose. Or try the  -Immediately if last run exceeds 24 hours - on a Temporary Daily Schedule and see if 24 works there - to find out quicker.

Edited by COStark26
Posted

@COStark26: The comparison with MBAM doesn't make sense to me. In case of EIS it is not "time since last miss", but it is "time since last run". So if EIS misses a dayly scan, then the time since the last run is always more than 24 hours.

Posted
1 hour ago, COStark26 said:

This Schedule logic contradiction thing is a wide-spread issue. The MBAM Setup screen can show - Recover if Missed by 1 hour - ( implies IF the computer wakes up at "8:00:01 or after" Following a Missed 07:00:00 Scheduled Scan, then Scan.) But 2 Clk's backing out to the Review Screen shows - "Run again Within 1 Hour of Last Miss (implies 07:00:00 asleep / IF the unit awakes between 7:00:01 and 8:00:01 Run the scan. If it doesn't, then DON'T Scan. HOW is that for clear Recover logic?

Interesting assumption.

Also to be factored in to this is how wake up from sleep mode is handled in Win 10. By default you are required to sign-on again after resuming from sleep. Also the subsequent activity that Windows performs is quite similar to that of done when signing in after a full boot; e.g. Win Update check, etc.. This could very well be the problem in that Eset's missed schedule scan internal clock is reset at log-on time.

It has been posted that the missed scheduled scan options also do not work on Win 7. So the issue might very well be that Eset's internal scheduler monitoring clock in regards to missed scans is reset after resume from sleep.

Posted
3 hours ago, AGH1965 said:

@COStark26: The comparison with MBAM doesn't make sense to me. In case of EIS it is not "time since last miss", but it is "time since last run". So if EIS misses a dayly scan, then the time since the last run is always more than 24 hours.

Forget the MBAM item; Just to show Recovery logic is problematic in other places.

Main idea was to TRY the 24 hour number Vs your Immediately If last run exceeds 1 hour.

Itman may be on to something in above post about Sleep and ESET clock re-sets - but were it me I'd try the 24 hour setting I suggested JUST to say you tried what MATCHES the ESET K-base Instruction.

Posted

OK, I will try the 24 hours setting, but remember that my original approach, i.e. using the "as soon as possible" option, didn't work either. So I think that the options for missed scheduler tasks are only present in the gui but not in the software underneath.

Posted

https://support.eset.com/kb3207/

Steps 6-7-8 show what I suggested you try; #9 shows In-Depth Scan but you should configure as desired.

IF this Fails then Marcos can tell the staff the K-base Instruction fails and to help with a Fix / different settings instruction.

Posted

The remarks of itman about resuming from sleep made me realise something. I'm having this scheduler problem in both Windows 7 and Windows 10, but in both Windows versions I disabled hibernation. In Windows 10 I even disabled the fast startup option. So every startup of my systems is a complete fresh boot. Could this be of influence for the scheduler problem? Does the scheduler of EIS perhaps rely on hibernation?

Posted (edited)
2 hours ago, AGH1965 said:

I'm having this scheduler problem in both Windows 7 and Windows 10, but in both Windows versions I disabled hibernation. In Windows 10 I even disabled the fast startup option. So every startup of my systems is a complete fresh boot. 

Same here on the Win 10 build I am running.

In theory, the Eset scheduled scan timing parameters should be controlled by following variables:

1. The last date/time a scheduled scan was run.

2. The date/time a scan is scheduled to run.

3. The Windows clock date/time. 

As far as Eset's KB3207 missed scan recommended setting of Immediately with a 24 hour interval specified, that is because:

Quote

To prevent instances of the same tasks from running on top of each other, we recommend you select Immediately, if time since last run exceeds a specified value. Type 24 in the Time since last run (hours) field

What the above implies to me is Eset by default will try to run the scan if missed.

I did notice something interesting for the only Eset provided scheduled scan that is time dependent; log maintenance. The time coded on my Eset EIS 12.0.31 installation is 6:00:15 PM. I find it a bid odd that thousandth of seconds is specified. Perhaps the issue is the coding of immediately if scan is missed is dependent upon such time specification? This time format coding along with an interval of "0" is what I am coding to try in my user created scheduled scan to see if it resolves the issue.

Edited by itman
  • 2 weeks later...
Posted

Time for an update. About two weeks ago a configured the scheduler of EIS as shown in KB3207, except I configured a daily scan at 18:00 and I restricted it to operating memory and boot sectors/UEFI. The results are very quite disappointing. In all those days, the scan was only run twice and that was when the pc was on at 18:00. This clearly demonstrates that the scheduler completely ignores missed tasks. The "Immediately, if the time since the last run exceeds a specified value" combined with "24 hours" as shown in KB3207 isn't working at all. ESET, please fix this!

Posted

My above posting of using thousands of a sec. in scheduled time field also did not work in starting of the scan upon resume from sleep mode.

Appears the only immediate solution to this issue is to set scheduled time to a time when PC is always powered on. Or, just initiate the scan manually.

Posted (edited)
On 1/4/2019 at 8:30 AM, itman said:

The time coded on my Eset EIS 12.0.31 installation is 6:00:15 PM. I find it a bid odd that thousandth of seconds is specified. Perhaps the issue is the coding of immediately if scan is missed is dependent upon such time specification? This time format coding along with an interval of "0" is what I am coding to try in my user created scheduled scan to see if it resolves the issue.

1/19: My above posting of using thousands of a sec. in scheduled time field also did not work in starting of the scan upon resume from sleep mode.

Not crucial to the issue BUT - I read 6:00:15 PM to be 6 PM - 0 Minutes - and 15 Seconds (ie) 15 seconds past 6 PM.  No?

Hopefully Marcos, etc., will just clarify that the Scheduler Will Never recover a Missed Scan after a Sleeping computer (at the scan time) wakes up.

Many can accept a fact; It's the Not Knowing /keep trying - failing that drives you crazy.

Edited by COStark26
Posted
43 minutes ago, COStark26 said:

Not crucial to the issue BUT - I read 6:00:15 PM to be 6 PM - 0 Minutes - and 15 Seconds (ie) 15 seconds past 6 PM.  No?

Correct. I stated so incorrectly. It shows seconds; not thousands of a second.

Posted (edited)

There is another work around for this problem.

You can create a .bat script containing Eset's command line ECLS scanner as shown here: https://support.eset.com/kb3417/?locale=en_US&viewlocale=en_US . Then create a scheduled task using Windows Task Manager to run the script. Assumed is you need to set the scheduled task to run with highest privileges.

-EDIT- Also in regards to using the coding shown in the KB article in a .bat file, I believe you need to add leading and trailing quotes to the entire string as shown below:

""c:\Program Files\ESET\ESET Smart Security\ecls.exe" /base-dir="c:\Program Files\ESET\ESET Smart Security" /auto /log-file=c:\ecls.txt /aind "

Ref.: https://ss64.com/nt/syntax-esc.html

Edited by itman
Posted

Even when someone uses an ESET forum to explain an alternative for an ESET tool, ESET remains silent. I'm disappointed.

  • Administrators
Posted

Please re-test it with v12.1 when released.

Posted (edited)

Marcos, I will surely do that. Does your reply mean that v12.1 has an updated scheduler? That would be fantastic!

Edited by AGH1965
  • Administrators
Posted

There was a bug in Scheduler fixed which might solve the issue you have. We also plan to overhaul the scheduler later.

  • 1 month later...
Posted (edited)
On 1/28/2019 at 4:11 PM, Marcos said:

Please re-test it with v12.1 when released.

Today first test done with v12.1.31.0. The modification has a strange side effect. Every time a scheduled scan with active "as soon as possible" option is added or edited, the scheduler seems to think that the scan was missed and starts it, even when it wasn't missed at all. That is rather annoying.

Edited by AGH1965
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...