EIS -- Always block this application (impossible to run) --program still runs/executes

[malik4477 0]

Hello, 

 

Why when I set a certain program as "blocked" --Always block this application (impossible to run) still the program runs..? I thought that it is impossible to run...? What's the use of stating there that it's "impossible to run" but i reality the Behavioral Blocker decides on it's own. I wanna set it to block as I do manual updating. I update after I do a system image backup so if there are issues I can just go and recover. 

 

See images below. 

 

 

 

 

I also wanna ask why the gui says always  "Initializing" but it's actually updating. See image below. Can't you fix this....? It used to be that when I right-click the tray icon >Update now, the gui shows exactly what is the percentage of the update. Now the last two version updates are like this. I have to point to the tray icon to see the status of the update. 

 

I am not always connected to the internet and the gui isn't helping me to be informed "properly" if the updates are pushing through or taking so long...to be informed of the status I need to point to the tray icon. This is annoying. 

 

 

Kindly explain please. 

[Aura 26]

Are you adding the "block" rule for the program when the process is running? Or do you kill the process, add the rule and then try to launch it again (and it works)?

[GT500 594]

The rule is only processed when the blocked program starts. If it is already running when you create the rule, the rule doesn't take effect until the blocked program is terminated, and then it won't be able to execute again.

There is a known issue with the update progress indicator in the UI. We have a bug report open on it, and intend on fixing it, however it is just a cosmetic issue and has no effect on the actual update process.

[malik4477 0]

posted by Aura

Are you adding the "block" rule for the program when the process is running? Or do you kill the process, add the rule and then try to launch it again (and it works)? 

 

posted by GT500

The rule is only processed when the blocked program starts. If it is already running when you create the rule, the rule doesn't take effect until the blocked program is terminated, and then it won't be able to execute again.

--- I created the rules from scratch so I did not run the program and wait for the pop-up so a rule will be created. If you know how and what EIS to implement a rule for programs you have. 

 

Rule has been created beforehand and before I launched the program. I just happened to glance at Process Hacker --check if some programs aren't blocked and there it was running even though the rule has been created already beforehand. 

 

To confirm I ran dragon.exe and also there it was dragon_updater.exe executed even thought (as stated) rules were created before launching the mother program. 

 

 

 

There is a known issue with the update progress indicator in the UI. We have a bug report open on it, and intend on fixing it, however it is just a cosmetic issue and has no effect on the actual update process. 

​-- Last time I checked it seems to be functioning now but it is intermittent. Still observing here. Thanks there. 

[GT500 594]

Rule has been created beforehand and before I launched the program. I just happened to glance at Process Hacker --check if some programs aren't blocked and there it was running even though the rule has been created already beforehand. 

 

To confirm I ran dragon.exe and also there it was dragon_updater.exe executed even thought (as stated) rules were created before launching the mother program.

Is the path for the file always the same? It's possible that there's more than one executable with the same name.

[malik4477 0]

Is the path for the file always the same? It's possible that there's more than one executable with the same name.

-- Yes path is the same. Thanks for the reply. 

 

Back here again,

 

Just got home and booted to the Win 7 partitio with EIS. Deleted all the rules for Comodo Dragon browser and Google Chrome browser and recreated it from scratch. Restarted and opened Process Hacker. GoogleUpdate.exe was the only one remaining there running after boot. The setting was as the same "Always block...". Deleted that particular rule for GoogleUpdate.exe, rebooted. Set the rule again as "Alway block...". Rebooted and there it was running again after boot. 

 

I had to use Systeinternals autoruns.exe to delete the scheduled task for Google Chrome update. Restarted/Rebooted. Check via Process Hacker if there was GoogleUpdate.exe running. There was none. 

 

So I think it was the deletion of the scheduled task that prevented it from running after boot and not EIS because if I did ot delete the scheduled task it still executed after boot. 

 

The rule is only processed when the blocked program starts. If it is already running when you create the rule, the rule doesn't take effect until the blocked program is terminated, and then it won't be able to execute again.

-- GoogleUpdate.exe and dragon_updater.exe executes upon boot. Do you mean that EIS cannot block that behavior (autorun upon boot) and needs the "blocked-program" be executed for EIS to be able to apply the created rule of "Always block..." ?

 

It has already been executed (autorun upon boot)... and EIS did not block GoogleUpdate.exe. 

 

 

I went to, 

 

C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

 

and double-click GoogleUpdate.exe and it was block but again it said that it was a virus. Thw wroding is misleading there. See image below. I rememebr I posted a similar observation previously http://support.emsisoft.com/topic/19332-always-block-this-applicationimpossible-to-run-because-the-file-contains-a-virus-etc/ 

 

 

Manual execution of GoogleUpdate.exe is blocked by EIS. 

 

Now for the gui --"Initializing but in actual it's already updating". In my other partition with EAM it's "Updating but the percentages are not in synch -- the tray icon seems t be correct always and notthe gui". I wasn't able to get the screenshots needed sorry. 

 

Well I guess that all it takes is that EIS updates. It's just that when your in a hurry and need to be atop of every minute that counts that is a bit annoying...(only a bit can live with that) . It's the block rule that I am not amenable. 

 

I can always install a 3rd party app like NVT_ERP or NVT_Smart Object Blocker but it would be redundant because EIS is powerful enough. That is why even I ahve MBAM Premium installed it's always used as on-demand. 

 

Will still be observing and comparing Win7 and Win 8.1 EIS behavior. 

[malik4477 0]

Back here for observations in Win 8.1. Rules were also the same for GoogleUpdate.exe. 

 

There is no "dragon_updater.exe" in the Comod Dragon Portable browser unlike in Win 7.  See image below. 

 

 

 

Launching Process Hacker there was no instances of blocked programs running. It was until I checked SystInternals Autoruns that in the Scheduled Tasks I have unchecked GoogleUpdate.exe. That maybe the case why there was no instance of GoogleUpdate.exe upon boot. See image. 

 

 

 

Manually executing GoogleUpdate.exe was also blocked with the same misleading words. See image below. 

 

 

Just to check I checked Opera browser's opera_autoupdate.exe and opera_crashreporter.exe.  Though the behavior is different --both only launch when launcher.exe of opera is executed manually. No instances of blocked programs seen. See images below. 

 

 

The issue with the gui is the same(wasn't able to get the screenshot sorry). 

 

Edit : This is the screenshot for the gui of Win 8.1

 

[GT500 594]

-- GoogleUpdate.exe and dragon_updater.exe executes upon boot. Do you mean that EIS cannot block that behavior (autorun upon boot) and needs the "blocked-program" be executed for EIS to be able to apply the created rule of "Always block..." ?

 

It has already been executed (autorun upon boot)... and EIS did not block GoogleUpdate.exe.

If the GoogleUpdate.exe process manages to execute before a2service.exe is active, then it will not be terminated. Blocked processes are only terminated when they are executed, so if they are running before a2service.exe then they will be left alone.

I went to, 

 

C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

 

and double-click GoogleUpdate.exe and it was block but again it said that it was a virus. Thw wroding is misleading there. See image below. I rememebr I posted a similar observation previously http://support.emsisoft.com/topic/19332-always-block-this-applicationimpossible-to-run-because-the-file-contains-a-virus-etc/ 

We are aware of the poor wording here, and I would believe we intend on changing it in the future since it isn't very clear.

Now for the gui --"Initializing but in actual it's already updating". In my other partition with EAM it's "Updating but the percentages are not in synch -- the tray icon seems t be correct always and notthe gui". I wasn't able to get the screenshots needed sorry.

We're aware of the issue with the progress indicator in the UI, and we do have a bug report open. I don't think it was fixed in the latest stable build, but an issue with the percentage shown by the System Tray icon was.

[JeremyNicoll 58]

One method of getting around this sort of thing is to replace the supplied  GoogleUpdate.exe  with another program, which does

nothing at all, but give it the same name.   If Chrome never notices that the 'GoogleUpdate.exe' is no longer its own one, it will

never replace it; and if you're not then running the updater it won't get updated by that either.  If Chrome checks that the registry

entry is still in place to run the updater, well, it will still be there, so that won't cause a problem either.

 

I use the DoNothing.exe  available from: http://www.stephan-brenner.com/?p=190 

 

If I were doing this I'd rename GoogleUpdate.exe to something else so I could still run it myself if I wanted to, then put a copy of

DoNothing.exe in its place and rename that to GoogleUpdate.exe  (and I'd probably also add a text file with a similar name with

a reminder of what I'd done).

[malik4477 0]

If the GoogleUpdate.exe process manages to execute before a2service.exe is active, then it will not be terminated. Blocked processes are only terminated when they are executed, so if they are running before a2service.exe then they will be left alone.

We are aware of the poor wording here, and I would believe we intend on changing it in the future since it isn't very clear.

We're aware of the issue with the progress indicator in the UI, and we do have a bug report open. I don't think it was fixed in the latest stable build, but an issue with the percentage shown by the System Tray icon was.

 

Thank you for the reply guys. 

 

@GT500,

 

On the gui updating issue and wording....will just wait for the fix.

On the GoogleUpdate.exe loading before EIS..hmmm..if Sysinternal Autoruns keeps it at bay for week or until there's another chrome update then I'll let it stand. 

 

Thanks Arthur

 

@JeremyNicoll,

 

Thanks for the tip there. I will check it out. 

[GT500 594]

On the GoogleUpdate.exe loading before EIS..hmmm..if Sysinternal Autoruns keeps it at bay for week or until there's another chrome update then I'll let it stand.

If you want to, then it should be possible to create a Scheduled Task that periodically runs and terminates GoogleUpdate.exe, or at least which runs around 1 minute after startup (or something like that). It might even be possible to have the task run only if GoogleUpdate.exe is running, however I'm not 100% certain about that (there's a lot of settings for Scheduled Tasks in Windows Vista and newer, and it's hard to remember all of them).