9 replies to this topic

[Mike_136]

Hi,

I have setup Windows 7 (64-bit) with ESET 4 and Malwarebytes Pro (v 1.60.xx onwards). In order to delay the MBAM Service by 20 secs (to avoid potential conflict with ESET at start-up) I do the following:

1. Change the start-up type for service "mbamservice.exe" to Automatic, from Automatic (Delayed Start).

2. Add a new DWORD Value "delayguistart" and set it to 20 at the Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Malwarebytes' Anti-Malware

This works great, however, I notice that the MBAM service can revert back to Automatic (Delayed Start). This leads to a much longer start-up (1-2 mins) and hence a delay in protection when online.

I have just isolated one thing that causes this change of the start-up type (back to delayed start). If I start the scanner and click onto the “scheduler settings” tab, without doing any changes even, I notice that the service is reset to delayed start. Why does this happen?

Secondly, I believe that updating the program version may also change the MBAM Service start-up back to delayed start. Can you confirm this? I isolate this by turning off the “program update” options within the “updater settings” tab.

Finally, I think I have noticed it change without the above 2 steps occurring. Are you aware of the regular identity updates triggering this action? Are you aware of anything else doing it?

It would be great if the user-chosen start-up type was never reset by the program. This would allow the program to start protecting the PC at the desired, shorter delay time and not after 1-2 mins.

Thanks in advance

Mike

[AdrianH]

1) I belive the delay is set to avoid the boot time scan that most decent AV's run and on Eset and Avast that can be in the first 1-2 minutes of starting.

2) The Malwarebytes system starts earlier than you may think, the GUI is certainly the last thing to be loaded.

[Firefox]

Hello and

If I do recall correctly, changing the service to automatic and then going into the scheduler does change it back. They are aware of that. That being said, you should probably leave it at delayed startup as that allows you ESET to start up first. You should not need the reg key. If you are having issues with them playing together, perhaps you should enter exceptions in your ESET av as outlined below.

For an example on how to setup exceptions in ESET Smart Security please see this guide that orubio provided right HERE.

[exile360]

Just FYI, we are considering changing the default startup behavior of MBAMService on Vista and Windows 7 to remove the delayed startup as we've been doing ongoing testing with a wide array of antivirus products and have eliminated nearly every incompatibility that we're aware of and are still working on any that remain, both on our end, and by working with the AV vendors themselves to get the issues resolved.

[Mike_136]

Hi Samuel,

Thanks for the update regarding the possibility of removing the delayed start. I've worked with ESET (and MB) for years and know there's no conflict with a 20 second delay (via the Registry DWORD). Can you not simply include an 'advanced' option (that I can enable) that prevents the resetting of the service to delayed start mode? Or, can you provide an option to enter a user-defined time delay?

Can you confirm whether a program update and/or identity update reset the service start-up mode, as asked in my original post? Thanks.

Cheers
Mike

[exile360]

Mike_136, on 02 May 2012 - 11:27 AM, said:

Can you not simply include an 'advanced' option (that I can enable) that prevents the resetting of the service to delayed start mode?

We have something better in mind (see below).

Mike_136, on 02 May 2012 - 11:27 AM, said:

Or, can you provide an option to enter a user-defined time delay?

That's the plan. We have decided that in a future release (though I don't know when yet), that we will be adding the 'delayguistart' function to the user interface so that it can still be delayed by the user if desired.

Mike_136, on 02 May 2012 - 11:27 AM, said:

Can you confirm whether a program update and/or identity update reset the service start-up mode, as asked in my original post?

Yes on both counts. Accessing the scheduler causes it to revert to a delayed start because whenever the scheduler is accessed, one of the things it does is make certain that MBAMService is installed and set to launch automatically (with our default delay of course) because it must be running for the scheduler to function. Updating the program also resets it for the same reason, because it reinstalls the service, which sets it to its default startup type (delayed in this case) because it is required for both the scheduler and the protection module.

I hope that helps to clear things up a bit, please let us know if you have any further questions or issues.

Thanks

[Mike_136]

Hi Samuel,

Thanks for the quick response.

Just to make sure I'm 100% here, as it stands it is NOT possible to keep the service on an Automatic (only) start-up, since the first daily (or hourly) identity update will simply reset the service to Automatic (Delayed Start), even with NO program updating enabled? Is this correct?

I don't quite understand the logic whereby accessing the scheduler automatically resets the start-up method to "delayed start". If the service is set-up to start Automatically (NO Delayed start) and is hopefully running, why can't the scheduler see that the MBAM service is running and therefore avoid the need to reset the start up mode? I can understand it resetting the service start-up mode IF the service had NOT started. I guess there's more to it than I understand?

I'm glad you're looking into incorporating the "delayguistart" function. Is this update likely in the coming months?

Mike

[exile360]

Mike_136, on 02 May 2012 - 01:07 PM, said:

Just to make sure I'm 100% here, as it stands it is NOT possible to keep the service on an Automatic (only) start-up, since the first daily (or hourly) identity update will simply reset the service to Automatic (Delayed Start), even with NO program updating enabled? Is this correct?

No, database updates (scheduled or otherwise) do not affect the service startup type, so it won't be reset by that. Only accessing the scheduler (i.e. visiting the Scheduler Settings tab under settings or clicking the Scheduler button on the Protection tab) or installing a new program version (not database version) will reset the startup type to delayed.

Mike_136, on 02 May 2012 - 01:07 PM, said:

I don't quite understand the logic whereby accessing the scheduler automatically resets the start-up method to "delayed start". If the service is set-up to start Automatically (NO Delayed start) and is hopefully running, why can't the scheduler see that the MBAM service is running and therefore avoid the need to reset the start up mode?

It's because it doesn't check, it simply makes sure that it will be running by resetting it (i.e. if the service were missing/broken for some reason, it would be reset so that it is functional as normal again).

Mike_136, on 02 May 2012 - 01:07 PM, said:

I'm glad you're looking into incorporating the "delayguistart" function. Is this update likely in the coming months?

As I said, I'm not sure when it will be, but currently the plan is to eliminate starting the service with a delay (setting it to Automatic instead of Automatic (Delayed Start) and adding that function to the user interface in case it is needed. When that will happen or in what version is still unknown at this point.

[Mike_136]

Hi Samuel,

Thanks for clarifying the database update details.

Many thanks for your help today.

Mike

[exile360]

You're very welcome Mike, I'm glad to be of service.

If you require any further assistance, please don't hesitate to ask.

Thanks