MBAM is not performing database update at Power-on (after being OFF overnight)

[DSperber]

I shut down my machine overnight and power it on sometime the next morning.  The OFF period is longer than the every-6-hours frequency I've got set for automatic database updates.  So there is guaranteed going to normally be one missed update in this overnight situation.

 

I've also got "recover missed tasks" checked and set to "recover if missed by 1 hour".  Presumably this means that if I miss the scheduled database update by at least 1 hour (which is true in my overnight OFF situation), it should then "recover" (i.e. "catch up") by performing the missed database update at the next opportunity.  In my case, it would be when the machine next gets powered back ON.

 

Also, I have MBAM set to "notify user if database is out-of-date for more than 1 day".

 

And finally, I have MBAM set to "delay protection at startup for 60 seconds", in theory to allow time for the internet connection to be established during Windows startup before releasing MBAM to try and phone home to update the database.

 

 

And yet... THIS DOES NOT WORK PROPERLY AS EXPECTED!!

 

Instead, either of two incorrect symptoms occurs:

 

(1) when Windows finally stabilizes after power-ON startup, MBAM shows the red exclamation mark as the database is out-of-date.  So I've been notified it's out-of-date, because the expected automatic database update (i.e. from the "missed overnight update" recovery) did not actually occur as it should have.  In fact, the missed update was NOT recovered as it should have been.  Instead I have to now manually "check for updates" myself.

 

or

 

(2) there is no red exclamation mark shown, suggesting that the missed overnight update was actually correctly "recovered" at Windows startup the next morning.  But apparently this is NOT what happened, since a few hours later I am now presented with "database is out-of-date" notification popup!  And I now must once again manually "check for updates" myself to resolve.

 

 

Bottom line: no matter what combination of values I've set for what seem to be the relevant program settings, the clearly missed overnight scheduled database update when the machine was powered off IS SIMPLY NOT RUN AS EXPECTED when the machine eventually next gets powered ON.

 

I do not want to be notified that the database is out-of-date when my machine gets powered on from being powered off overnight.  I simply want the program to automatically "catch up" and perform the expected "recovery of missed update" at this next opportunity, quietly and automatically.  That will bring the database up to date and I should then not ever see "database is out-of-date".

 

But this is not working as I expect (and which seems like it should be working), probably because of some wrong settings that I have. Or else it's a program bug.

 

 

So, please help me:

 

(1) what should my settings be to guarantee quiet and automatic performance of database updates when the machine is next powered ON after being shut down the night before, where at least one automatic scheduled update is pretty much guaranteed to be missed while OFF?  I want this "missed update" to be recovered and performed automatically at the next opportunity.  I do not want to be bothered with "database is out-of-date" popups, and I do not want to have to manually "check for updates" myself to resolve.

(2) or is it a program bug, and this is simply not working as designed???

 

thanks.

[Maurice Naggar]

Hello,

 

Be sure to have the latest program version 2.0.2.1012.

 

Then I would suggest these settings:

Take a look inside the program. Start the Anti-Malware. Click on the Settings icon at the top bar up at top.
Then click the **Advanced Settings** button at the left.
Be sure all top 3 lines on that window are check-marked ( selected ).

Now a couple of changes for each of the Update task & the Threat scan task in the Scheduler.
Click on **Automated Scheduling** button.

Locate and click once on **Check for Updates** line and press Edit. Then press the Advanced button at bottom left.
Slide the window up so you can see all of it. {press the mouse on the very top bar and slide UP }
A few changes are needed.
Look at the "starting time" of the task and use some good time when you know that your computer will be on & powered & that Windows would be on at that time.
Look at the line in Schedule Options. UN-check "Show notification after successful update".

In the Frequency and Settings. Select Hourly and I suggest using the Recurrence at 4 hours.
In the Recovery Options put a check-mark on "Recover missed tasks" and select 1 hour
When done, press the OK button.

Locate and click once on the Threat Scan line and press Edit.Then press the Advanced button at bottom left.
Slide the window up so you can see all of it. {press the mouse on the very top bar and slide UP }

In the Schedule Options, put a check-mark on the line Terminate program when no threats are found
{when no malwares are detected you want the scheduled task to close}.

In the Frequency and Settings block.
You should have Daily and the recurrence set to 1 day.
now UN-check the line Check for updates before scanning {{that line should be always off otherwise the task may not run at the time set. It maybe run +/- 15 minutes of that period.}

In the Recovery Options put a check-mark on "Recover missed tasks" and select 1 hour
When done, press the OK button.

When completely done, close the window.

[DSperber]

I have two machines.  One runs 24/7, so of course there is no problem performing the regularly scheduled updates on my prescribed regular schedule.  Program works fine, as long as it doesn't have to "recover missed updates".

 

It is the second machine which is powered off every night and powered on again some time the next day, although it might be off for many days or even weeks if I'm out of town before eventually being powered back on.

 

I don't care HOW LONG IT'S BEEN OFF... when it's next powered back on I want this machine to ALWAYS do a SILENT AND AUTOMATIC database update (and probably a threat scan as well) to get things back operating normally again.

 

I am well aware that because the machine was powered off during the scheduled update times for these two items it was clearly impossible to perform those scheduled updates.  This is common sense.  I simply want the program to "catch up" by itself, quietly and without involving me, doing whatever missed database update and threat scan it needs to do... exactly as implied by the "recover missed updates" option English wording.

 

However... THIS DOES NOT SEEM TO BE HAPPENING!!  The program does NOT appear to be performing as expected, given the settings I already had (and which were very much like the ones you recommended... which if they were "correct" then why aren't they the official "recommended settings" that appear by default when you install the program??).

 

IT WOULD APPEAR TO BE A PROGRAM BUG, that the "recover missed updates" function is NOT behaving as expected.

 

Just for example, a short while ago I turned on the machine after being off for about 16 hours.  And instead of SILENTLY just performing the expected missed update (i.e. "recovering" the overnight missed update because the machine was down), it DID NOT UPDATE!!  Instead, it notified me that the database was out-of-date thus requiring me to manually "check for updates".  The initial database shown was 06.21.10, and after completing the manual update it was now 06.22.06.

 

So... in my opinion there are TWO things wrong:

 

(1) the expected automatic "recover missed update" did not occur even though my setting is (and always WAS, for that matter) "recover if missed by 1 hour" exactly as you recommended.

 

(2) the original database version (06.21.10) was NOT more than 1-day out-of-date, since the eventual updated database is 06.22.06.  Yes, it is from a new day, but it's not "24 hours" newer (which presumably would have been 06.21.10).

 

 

MB needs to try this themselves, and confirm that the program is or is not working as intended.  It's obviously an easy test... just turn a machine off overnight and power it on the next morning, thus forcing it to miss at least one normally scheduled database update.

 

 

[DSperber]

NOTE: if the program is:

 

(1) mistakenly (in my opinion) testing for out-of-date database FIRST (i.e. before actually performing the missed update), and

 

(2) if that 1-day test only looks at the database DATE (i.e. 06.21 on my system vs. 06.22 latest version, which is certainly at least 1 day different) rather than also including the database version (i.e. 06.21.10 on my system vs. 06.22.06 latest version, which is certainly NOT a full 24-hours or 1-day newer), and

 

(3) if the out-of-date database discovery NOW PREVENTS PERFORMING (i.e. "recovering") THE MISSED UPDATE because the user has to be notified of the out-of-date database condition,

 

then THIS IS A PROGRAM DEFECT!!!

 

It is GUARANTEED that the database will be out-of-date if it's powered off overnight and not powered on again until the next day, or days later, or weeks later.  That is EXACTLY WHY the "recover missed updates" option exists, to handle exactly this situation.  Quite frankly I think the program should simply always do the missed update and not even be controllable via setting, but if you're going to have a setting then you should always do the MISSED UPDATE RECOVERY FIRST... before then checking for database out-of-date.

 

In other words, if the regular scheduled updates are working (as long as the machine is powered on and running normally), then it's impossible for the database to be out-of-date (unless there's something wrong and inconsistent with the settings values).  And if upon power-ON following a long power-OFF state the desired "recovery of missed updates" is silently and automatically performed FIRST, then again the database will NOT be out-of-date once the missed database update is completed.

 

So as long as database updates have not themselves been thwarted by malware, the database should NEVER EVER get to an out-of-date condition.  And by performing regular or "recovery of missed" updates first, and check-for-out-of-date-database second, I will NEVER see what I'm currently seeing, i.e. the notification that the database is out of date.

 

It's only if somehow malware has gotten into the system which is now preventing the automatic or "recovery of missed" updates from keeping the database current that I should ever conceivably get to a state where the database is stale and truly out-of-date by more than my settings value, thus now justifying the "out-of-date database" popup and message notifications, thus alerting me to a true problem.

 

So the program should be checking for out-of-date database SECOND, not first.  Do the scheduled or "recover missed" update FIRST, and then check for out-of-date database SECOND.  As long as things are operating normally, the database should NEVER be out-of-date and I will NEVER see the "out-of-date database" notifications.

 

It is clearly a program bug (in my opinion) that it must be checking for out-of-date database FIRST (i.e. in the wrong sequence), that it will now ALWAYS DISCOVER OUT-OF-DATE DATABASE following a situation like the long power-OFF state, which is the problem condition I'm reporting.

 

 

PLEASE... TRY THIS IN YOUR DEVELOPMENT LAB, and confirm for yourself that the program seeming has been coded BACKWARDS, and is currently mistakenly testing for out-of-date database BEFORE IT SHOULD!!  It is now ALWAYS producing "out-of-date database", and is NEVER performing the "recover missed updates".

 

That's just the facts.

[DSperber]

I hadn't seen it before now, but there does appear to be an essentially duplicate thread posted by another user... reporting the identical problem as I'm reporting in this thread.

 

I guess I'm not alone.

[DSperber]

To try and assist your team in getting to the bottom of this, it appears that the Scheduler is simply NOT kicking off the database update after a long period of being powered OFF before then being powered back ON. 

 

==> The "recover missed updates" functionality APPEAR TO SIMPLY NOT BE WORKING!  I myself must MANUALLY initiate the "check for updates" after powering on, as this is NOT HAPPENING THROUGH SCHEDULER.  (Application logs screenshots below confirm and prove this)

 

 

I currently have hourly database updates scheduled, and I have 1-hour as the "recover missed update if missed by X hours" time value trigger.  I have 1-day as the "notify user if database out-of-date" limit.

 

This is infinitely simple for MB to demonstrate for themselves, to confirm or deny that the feature is or is not working as designed.  I claim it is NOT working as intended.  Just simply turn one of your own machines off tonight, say at 11PM.  Leave it off all night, and then power it on again say at 10AM tomorrow morning.  What happens??  Does the scheduler kick off immediately to "recover missed updates", or does it not??

 

See for yourself if it duplicates my experience, and the experience of a number of other users (posting here, as well as on the SevenForums "Security" forum on a similar thread about this identical topic).

 

 

You have asked for some application logs, so I'll provide them here.  See screenshots below (a picture's worth 1000 words), for logs starting from today and going back about 10 days. I made the most recent settings changes (to 1-hour database update frequency) sometime on 6/22, along with changing the "next scheduled update" date to be shortly in the future, to guarantee I was conforming to the recommendations you had provided earlier in this thread (on 6/22).

 

Note the presence in the logs of my "manual" updates to fix the database out-of-date problem, vs. when the "scheduler" database updates did or did not occur naturally, for each day's log.

 

Note that back on June 22 you responded with some recommended settings values.  Shortly after that I DID make these changes (as acknowledged in this thread), but seemingly with no permanent difference in results.  Before going to 1-hour update frequency I was at 6-hour update frequency.

 

The scheduler was still NOT KICKING IN AT WINDOWS STARTUP to "recover missed updates" as it should.  I did have one surprise day where it seemed to work (perhaps right after I changed the "next scheduled" date/time to be within the next hour or two from when I was changing settings), but the past few days has seen things go back to the way they were.

 

I have now just re-booted after the machine being off of for about 14 hours.  And... as I have been trying to convince you... I see "database out-of-date" and I must manually initiate database update myself.  The automatic expected "recover missed update" function SIMPLY DOES NOT WORK.

 

 

 

 

 

 

 

 

 

[DSperber]

Here are the rest of the application log screenshots going back to June 13.

 

 

 

 

 

 

 

[DSperber]

Oops... sorry... an early image in the fist post of this group was incorrect.  But your forum software doesn't seem to provide any way to EDIT (at least not that I can see).

 

So here is what should have been posted, showing the "out-of-date" database condition and its initial last-updated version of 06.24.03.  This is before I manually did my "check for updates" to bring it current to the 06.25.19 value you see in the later screenshot.

 

[Porthos]

Just a personal non staff opinion.

 

I currently have hourly database updates scheduled, and I have 1-hour as the "recover missed update if missed by X hours" time value trigger.  I have 1-day as the "notify user if database out-of-date" limit.

 

I change the value to more than one day. ( in my case 3-5 to account for longer time off.)

[DSperber]

Just a personal non staff opinion.

 

I change the value to more than one day. ( in my case 3-5 to account for longer time off.)

 

I believe that while changing the "out-of-date" trigger value to be larger than 1 day, this is not actually a solution to the seemingly obvious program bug that "recover missed updates automatically" is simply NOT WORKING!!  The logs prove that.

 

The notification about "database out-of-date" appears to occur FIRST, and also seems to then be preventing the automatic "recover missed updates automatically" from happening.  It seems obvious that the notification should occur SECOND, and the "recover missed updates" function should always kick in immediately upon startup, to "catch up" from missed updates while the machine was off.  And now, once the missed updates have truly been "caught up", well now you can check for "database out-of-date" and of course it should NOT be true... ever, if "recover missed updates" is actually working correctly!

 

Yes, if you increase the notification duration beyond 1 day, and if somehow you eventually reach the next automatically scheduled or before that time hust manually perform a database update which works, well this is all just workaround for the fact that "automatically recover missed updates" is simply NOT WORKING AT ALL!  Or, perhaps the scheduler is just being suppressed because the notification of database out-of-date test is being performed before it (and thus inhibiting the desired "automatic catch-up") when it should be performed after the guaranteed missed database updates are recovered as intended.

 

 

==> This is clearly a program bug.  It is NOT working as designed.  MB can easily demonstrate this for themselves, just by turning off one of their machines TONIGHT and turning it back on tomorrow afternoon.

 

The fact that they won't do this simplest of experiments in their own shop is very strange indeed, since it's "ostrich behavior" (i.e. sticking your head in the sand simply denying that a bug can even possibly exist).

 

I thought this was a support forum, where we interact with MB and report problems and work together to try and resolve (if it's a user error), or document a verifiable progrma bug (if it's a program error).

[DSperber]

Is there ANY way to do an "edit" on a post using this forum's software???

 

I'd sure like to correct some typos in things that are up there, but "edit" doesn't seem to be available, unless I just don't see it.

 

Anybody?  Is it just me not seeing the obvious?  Or is it impossible to make an "edit" even for the simplest of spelling errors or typos or other more substantive mistakes, or to make a correction or addition, or anything??

[Porthos]

Is there ANY way to do an "edit" on a post using this forum's software???

 

I'd sure like to correct some typos in things that are up there, but "edit" doesn't seem to be available, unless I just don't see it.

 

Anybody?  Is it just me not seeing the obvious?  Or is it impossible to make an "edit" even for the simplest of spelling errors or typos or other more substantive mistakes, or to make a correction or addition, or anything??

Edits are enabled after 100 posts. ( Too much abuse.)

[DSperber]

MB support: I have posted sample logs above for the past 10 days.  It shows that "scheduler" is not running when the machine is first powered on having been off for the night before.  Only "manual" is how I get the updated database.  Once manually started, normal scheduling WILL occur regularly throughout the day, at least until it is again powered off at night... in which case once again the "recover missed updates" function does NOT work the next time the machine is powered back on.

 

This is TRIVIAL for you to try yourself (say tonight!) and prove to yourself that the problem exists.  The "recover missed updates" function is simply not working as you intended.

 

And then, when you can see for yourself that the problem truly exists, you can fix it!

 

I am not alone in observing and reporting this problem.  Other users (both here on this forum, as well as on SevenForums) are reporting this identical issue. It's not just me.

 

If anybody from MB is reading this thread, I plead with you to just turn your computer off tonight, and then turn it on again tomorrow, and see if the log shows "scheduler" or not, as proof that the "recover missed updates" function is or is not working as you think it should.  I'm certain it is NOT working properly, and you can easily answer this mystery yourself... tonight, using your own machine.

 

We'd sure like it if you would acknowledge the defect and fix it.

 

Thank you.

[1PW]

Hello DSperber:

Your computer's Malwarebytes Anti-Malware issue has been re-escalated to the Malwarebytes staff.

Thank you for your patience and understanding.

[AdvancedSetup]

I'm going to submit this to our QA department and see if they can duplicate the issue and possibly resolve it. They're quite busy so it may take them a few days to get to it. If no response within a couple days please send me a follow-up PM.

[exile360]

I haven't read through the entire thread, but I'll try to help as best I can based on your first post:

• Click on START and choose Run and type services.msc and press Enter
• Scroll down the list of services until you find MBAMScheduler and make certain that it is set to Automatic (not Manual or Automatic (Delayed Start))

Once that's done, open Malwarebytes Anti-Malware and access the Automated Scheduling tab and edit your scheduled update task by changing the Recover if missed by setting to 23 hours instead of 1 hour (it recovers if the scheduled task was missed within the recovery time, not in excess of it).

Additionally, delaying protection start has no impact on the scheduler. The scheduler runs when the service launches. Also, if the scheduled task executes but fails to actually update due to your internet connection not yet being ready/active, it will not recover and will instead wait until the next scheduled update is set to occur.

The most surefire way to ensure that the update kicks off once your computer boots and the internet is online until we have implemented an improvement in our own code to address this scenario would be to use a tool such as Startup Delayer to delay the startup of MBAMScheduler by 2 minutes or so (depending on how long it takes your internet connection to become active during the startup process).

[DSperber]

I haven't read through the entire thread, but I'll try to help as best I can based on your first post:

• Click on START and choose Run and type services.msc and press Enter
• Scroll down the list of services until you find MBAMScheduler and make certain that it is set to Automatic (not Manual or Automatic (Delayed Start))

Thank you very much for your reply.

 

Since the forum software doesn't seem to allow me perform "imbedded quoted text" (with my reply following each snippet of quoted text from your post, so that I can respond to each thing you say clearly and individually), I will simply respond to one of your points at a time... in multiple reply posts of my own.  Sorry for this, but I don't know if there is actually a way to do what I want.

 

 

Anyway, MBAMScheduler is absolutely currently in a status of "STARTED", with a startup type of "AUTOMATIC".

 

So this looks fine.

[DSperber]

Once that's done, open Malwarebytes Anti-Malware and access the Automated Scheduling tab and edit your scheduled update task by changing the Recover if missed by setting to 23 hours instead of 1 hour (it recovers if the scheduled task was missed within the recovery time, not in excess of it).

 

 

Well. this obviously makes ALL THE DIFFERENCE IN THE WORLD!

 

Why doesn't the MBAM "support guide" page describing the Automated Scheduling settings make this crystal clear?  As it reads right now, there is nothing at all to indicate that this number of hours value is the "missed within this number of hours" recovery time period, as opposed to "if missed by at least this number of hours".

 

Instead, the "support guide" page is truly completely ambiguous and non-informative, reading: "Recovery Options allows you to perform a database update if you missed your scheduled one, and define what constitutes overdue."  I really don't know what that means.

 

But your true clarification of this value really does clarify things.  Now I take it to be saying "if a scheduled database update is missed within this number of hours, then perform recovery of that missed update".

 

Now for some questions:

 

(1) Why don't you have 23 pre-populated by default when the program is installed?

 

(2) Why did one of the MB support people recommend that I specify 1 hour here (see response by Maurice Naggar as post #2 in this thread), if 23 is clearly the right value?

 

(3) Why is ANY value or option here appropriate?  Why doesn't the program just ALWAYS catch-up on a missed update?  Why would I EVERY want it NOT to catch-up on a missed update?

 

(4) What is I'm away on vacation for a week, and come back and turn the machine on.  This is going to be a "missed update interval" of greater than 23 hours, and yet I still do want the program to just ALWAYS catch up automatically for ANY missed update situation?

 

(5) Why is there ANY NEED FOR A USER SETTING at all here?  Why not just write the program to ALWAYS do a catch-up of any missed scheduled updates at the next opportunity???  This would cover ANY situation, including the machine being off for weeks and then getting powered back on.  At this opportunity, just catch up.  Period.  Quietly and silently and automatically.  Why do I have to tell the program to do that, and why is 23 hours the maximum such duration I can specify when obviously it can be days or weeks since the last update when the machine has been powered off?

 

 

Anyway, I will make this change.   Given how you've now explained what it really means, it's now clear why my automatic catch-up "recovery of missed updates" is NOT occurring... because if the machine is off for 16 hours that's obviously not within the 1-hour missed update interval as is currently set.  It is now completely obvious that I need to have a value LARGER THAN 16 HOURS in order to have automatic catch-up performed.

 

Again, I think this is just a silly program design.  Why would I not want this to always happen automatically at the next possible opportunity, no matter how long the machine has been powered off for??  I feel that's the way the program should just work.  Period.

[DSperber]

Additionally, delaying protection start has no impact on the scheduler. The scheduler runs when the service launches. Also, if the scheduled task executes but fails to actually update due to your internet connection not yet being ready/active, it will not recover and will instead wait until the next scheduled update is set to occur.

 

 

I see.  I really didn't know it had no impact on the scheduler, and was simply trying whatever I could think of to eliminate any possible cause that I thought might be responsible for what was happening.

 

It is now clear that setting 1 hour as that "missed update" value is definitely the wrong value to specify, if the machine is going to be powered off for more than 1 hour.  Obviously having a value specified here that is LARGER than the expected time the machine is expected to be powered off is the correct value to specify.  Hence your common sense suggestion for 23.

 

And again, my common sense question is why not allow me to specify a value of "infinity"??  This would mean "ALWAYS catch-up for any missed update, no matter how long that duration is from when the scheduled update should have been performed until now".

 

And if "infinity" is a new possible value, then really... why have this setting at all?? Don't you think the program should just ALWAYS catch up when a database update is missed, without notifying me "hey... the database is out-of-date" which requires me to manually "check for updates" to clear up the situation?

 

This is really unnecessary.  Just make the program always do the missed update(s) at the next possible opportunity, i.e. when the machine is finally powered on  and the scheduler service started and the database is discovered to be out-of-date because at least one scheduled update was missed.

 

==> Don't bother me with "your database is out-of-date" notification, requiring me to manually "check for updates".  Just do the update automatically, and it will now NOT be out-of-date, and in fact will NEVER be out-of-date!

[DSperber]

Well, latest update: YOUR SUGGESTION TO CHANGE THE MISSED RECOVERY PERIOD TO 23 HOURS WAS A COMPLETE FAILURE!!!

 

==> The program is simply broken, and this functionality to catch-up and recover a missed update JUST DOES NOT WORK AS YOU HAVE INTENDED!!!

 

 

Today is Thursday 6/26.  I turned the computer off today at around 3PM in the afternoon, having initially powered it on (from its OFF state from the night before) earlier in the afternoon at around 1PM.

 

I then turned it on again at about 11:50PM tonight, so on Thursday it was OFF from around 3PM until around 11:50PM (just before midnight) when it got powered back on.

 

The day before, Wednesday 6/25, the machine was first powered on at around 2:55PM in the afternoon, remained on all day, and then was powered off sometime before midnight.  It remained powered off until getting powered back on again Thusday afternoon at around 1PM as mentioned above.

 

And, as you can see, I have now today (at 11:50PM on Thursday evening) been notified about "database out-of-date" with the System Tray icon showing the red exclamation mark.  This is the result of powering the machine ON at 11:50PM, having been off from around 3PM earlier today until just now.

 

 

So now I must manually perform "check for updates" to clear up the situation, since the program is NOT doing this automatically for me which was I imagine the exact intention of the "recover missed updates" functionality.

 

==> THIS "RECOVERY MISSED UPDATES" functionality IS SIMPLY NOT WORKING!!!   Please recognize that (many other people are posting about the identical issue), chase it down, and fix it!!

 

 

And as you can see from the program dashboard, there has not been a database update since sometime earlier, as the database version shown is 06.26.02  However as you will see from the logs posted below from 6/26 and 6/25, the update to version 06.26.02 actually DID NOT OCCUR ON 6/26, but instead actually occurred late in the evening of 6/25 (at 10:32PM, from an automatic scheduler-initiated database update as shown in the 6/25 log below):

 

 

 

Here are my program settings for automated database update, including the "advanced" settings about supposedly automatic catch-up to "recover missed updates". Note that the automated database frequency is every 4 hours (if the machine is left powered on), and the missed update recovery duration specification value is 23 hours, as you suggested... even though it now appears to have had no effect (or, perhaps even the opposite effect that was intended) since THERE WAS NO RECOVERY UPDATE BY SCHEDULER when I re-booted the machine at 11:50PM tonight. 

 

 

 

Looking at the two logs covering (1) all day 6/26, as well as (2) the prior day 6/25, you can see that the program is simply NOT performing the manual "recovery of missed updates" when it gets powered on.  PERIOD!  NOT DOING IT.

 

Notice from the 6/25 log that once I did my own "manual" database update at 3:44PM in the afternoon, there were in fact then two subsequent "scheduler" database updates later in the day as the machine remained powered on until nearly midnight on 6/25. These "scheduler" updates did occur roughly at the every-4-hour frequency as  I have set.  The last update on 6/25 at 10:32PM in the evening is the one which updated the database to 06/26/02, and this is the very last update performed.

 

 

 

 

 

Do you agree that this is undeniable irrefutable proof that this "recovery of missed updates" functionality IS SIMPLY NOT WORKING??

 

Have your technicians performed their own ultra-simple experiment for themselves tonight, turning off their own machine when they went home for the night and then powering it back on tomorrow morning when they come in, to see what happens?

[DSperber]

Have your technicians performed their own ultra-simple experiment for themselves tonight, turning off their own machine when they went home for the night and then powering it back on tomorrow morning when they come in, to see what happens?

 

I guess by the absence of response from MB that this recommended in-lab proof of failure is too much trouble for your technicians to perform themselves, i.e. taking the few required seconds to turn off their machine when they leave for the night and turning it on again the next morning. 

 

This overnight experiment would, of course, instantly demonstrate the MBAMScheduler service is NOT working as designed, and does NOT "recover missed updates" at all.

 

I give up.  I guess MB just doesn't care about this one enough to fix it... or even to demonstrate it for themselves in the lab and admit it here.  Very very disappointing.

 

As it turns out, even though the "recover missed updates" doesn't work at all when the machine is powered back on, eventually the normal next-scheduled update will get performed and kick-start things back into normal periodic updates... at least for as long as the machine remains powered on.  Of course the problem recurs again whenever I power the machine off, and don't power it on for a while.

 

If it weren't for the annoying "database out of date" notifications that accompany the failure of "recover missed updates" to be performed, I guess I could realistically live with this program defect.  But after all, the out-of-date conidtion will only last for a few hours before the next scheduled automatic update kicks in.

[KenW]

My desktops are off over night. Automated Scheduling date/time is the time MB was installed. I always reset the time to 3-4am so the hour is up before I usually boot up around 7am. MB updates within a few minutes after boot.

[KenW]

Forgot. I was getting update warnings until I changed Update Settings/ Update options to TWO days. It had something to do with the date and time for the next days update. Here in Colorado the time was around 7pm which would make MB think the first day was missed.

[DSperber]

My desktops are off over night. Automated Scheduling date/time is the time MB was installed. I always reset the time to 3-4am so the hour is up before I usually boot up around 7am. MB updates within a few minutes after boot.

I understand this "trick".  And of course I could simply always just "check for updates" myself shortly after powering the machine on and Windows desktop initialization settles down.  Really not the end of the world.

 

However this really is just "ostrich reaction behavior" to the fact that this presumably is supposed to happen automatically as a result of the "recover missed updates" functionality and associated "advanced setting".  What else would this be for??

 

So if there's a program bug, and a designed feature isn't working as intended, shouldn't that be acknowledged and put on the "to-fix" list?

[DSperber]

Forgot. I was getting update warnings until I changed Update Settings/ Update options to TWO days. It had something to do with the date and time for the next days update. Here in Colorado the time was around 7pm which would make MB think the first day was missed.

Again, more "trickery" to try and get around the unintended consequences of the bug, which is what makes the bug annoying.

 

Workarounds work, to hide the underlying problem.  This is a benign problem, with a reasonably simple workaround, to either just suppress the notifications about "database out-of-date" until the next normally scheduled update kicks in to resolve the problem naturally, or to just always take a few seconds to "check for updates" as part of the morning re-boot Windows startup agenda.

 

But again... these are user-discovered workarounds for a defect in the software itself.  We're reporting the defect (or trying to, anyway) to the vendor, and there have been a number of identical reports on this and SevenForums by a number of users.  The built-in software feature to deal with missed updates was built to deal with missed updates, and it would not appear to be working.

 

Seems simple enough for MB to demonstrate for themselves, and then chase down and fix.