What if emergency update doesn't run?

[cooby]

Because of the random file names (discussed here a million times) the update doesn't run because it's blocked because I wasn't sitting at the computer to permit a new .exe to run when it came and only saw it in the logs that it was blocked? Twice recently.
Subsequent stream updates are ok, but that's not the engine fixes that emergency apparently does.
So am I doomed forever now? I see no evidence of Avast retrying that randomName.exe later.

Edit: I see that I missed two just today    

[GreggH]

Cooby.... a very good question. In my case, I don't miss them by not being at the computer... I miss them because my computer is on 24/7 and only gets rebooted when/if I install something (like Windows Updates) that requires a reboot. Since this happens only rarely, I have no idea what emergency updates are there or have been missed because I didn't restart my box before the next one came in to supersede an earlier one. IMHO, sending an "emergency" update without informing the user that it is there and/or he should restart his computer to apply it is a big mistake. I am sure that you and I are not the only ones out there out of 200 million users who have such issues, except that many people may not even know about having them, if they are like me and don't restart often.

Gregg

[cooby]

Emergency updates sometimes come at boot time. Most of the time they come during the day at unpredictable moments and with unpredictable filename.
If permitted, after emergency update runs, reboot is NOT required. That's the beauty.

The ugliness is that a brand new .exe has to run and good security software blocks unknowns. That is precisely what I saw yesterday twice and many, many times before.
Take a look here for instance - it's just two of many discussions on the subject
http://forum.avast.com/index.php?topic=142451.0
http://forum.avast.com/index.php?topic=145371.0

Emergency update is not the same thing as streaming update or any other definitions update.

[GreggH]

Emergency update is not the same thing as streaming update or any other definitions update.

There are two forms of Emergency Updates, one which is the normal, expected emergency update, and another which is set up in your registry as a "Run Once". This second one uses EXE files with random names, and, as the registry entry implies, is only run once, when the system reboots and that section of the registry is read and acted upon. In my emupdates folder, I have two remaining random named files, one dated Mar. 26th, the other the 28th. Had the Run Once been acted upon correctly, these should have been removed when run, which implies that they were not run, or at least, to me does so, based upon my knowledge of that registry entry. And the reason they were not run is that my machine was not rebooted at any time during that period. I can assume that, since the Run Once entry is not in my registry now, when I did reboot my system after Patch Tuesday this month is when Run Once was run and the file which it acted upon was removed, leaving behind two that have not been acted upon.

It is this form of "emergency" updates which concerns me, in that, it is more than possible to receive one of more and not have them actually run, if you do not reboot, which, to my way of thinking, makes them "non-emergency" updates, OR using Run Once in the registry for emergency updates is a poor method of handling them.

Gregg

[Gopher John]

I think that the files left in the emupdates folder are the result of poor housekeeping on Avast's part.  I reboot soon after receiving notification of an EMupdate by WinPatrol, and the update is applied.  However, the files remain.

[cooby]

I think I was wrong in reply#2 about no need for reboot.

If permitted, after emergency update runs, reboot is NOT required. That's the beauty.

I read some old info, and apparently emergency jobs make reinstallation not needed, nothing to do with no-reboot.

GreggH,

There are two forms of Emergency Updates, one which is the normal, expected emergency update, and another which is set up in your registry as a "Run Once". This second one uses EXE files with random names, and, as the registry entry implies, is only run once, when the system reboots and that section of the registry is read and acted upon.

I understand what you wrote. But I don't think it's like that on XP. Soon after it was blocked today, I checked the registry, and I didn't/don't have a thing anywhere in RunOnce. Maybe it's like that on Win7.
I also understand the process. Emergency update runs to check is one scenario. The second is when it brings in that random named file, and it's this one I wonder about what happens when it wasn't permitted to run.

Gopher John,

I think that the files left in the emupdates folder are the result of poor housekeeping on Avast's part.  I reboot soon after receiving notification of an EMupdate by WinPatrol, and the update is applied.  However, the files remain.

I don't have any old files in the defs nor under All users. Certainly not the randomName.exe.

So, does it go into bit bucket when it's never allowed to be installed due to its crazy filename?
And if it won't run many times, perhaps it indicates that those Emergency (engine) updates aren't needed as, I think, GreggH implies

Over past few months I've been contemplating ditching avast. Not because of the sales popups. Not even about the non-working exclusions. But this, the random filename issue. But there's nothing as small and good as avast out there!

[DavidR]

<snip>
Gopher John,

I think that the files left in the emupdates folder are the result of poor housekeeping on Avast's part.  I reboot soon after receiving notification of an EMupdate by WinPatrol, and the update is applied.  However, the files remain.

I don't have any old files in the defs nor under All users. Certainly not the randomName.exe.

So, does it go into bit bucket when it's never allowed to be installed due to its crazy filename?
And if it won't run many times, perhaps it indicates that those Emergency (engine) updates aren't needed as, I think, GreggH implies
<snip>

I don't know if you are looking in the right place, since you talk of the defs and All Users folders, it is in the main avast program folder, not All Users - but in the C:\Program Files\AVAST Software\Avast\Setup\emupdate sub-folder.

I had tons of them in the past (well six), so avast housekeeping isn't removing old em update files after use I also had two sub-folders named in the same style as the unique file named executables in the emupdate folder. I disabled the self-defence and removed the old files.

@@@@
Getting back to the original question - there is a Scheduled Task (hidden) that runs twice a day and that checks for the presence of an emergency update. If there is one then this AvastEmUpdate.exe file should create the unique file name and the RunOnce entry in the registry.

So if you happened to miss an emergency update, then this scheduled task should check again.

[cooby]

DavidR, thanks for pitching in.
Sorry about my mental shortcut defs=C:\Program Files\AVAST Software\Avast\defs not really relevant here.

Today, two randomName.exe files came in. the last one was at 21:51:02.
As usual, avastEmUpdate ran, it then tried running C:\Program Files\AVAST Software\Avast\setup\randomName.exe and was blocked.
The commands were:
C:\Program Files\AVAST Software\Avast\setup\4598e7e2-f750-42ab-8939-5ad4b0827ae8.exe
C:\Program Files\AVAST Software\Avast\Setup\37b51beb-c180-47d9-9868-7ebdc6ae2d8d.exe
Those .exe files are NOT here anymore. I saw none this morning and none now. Or really never. I've been trying to figure how it works many times.

Hunting in other places:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
- all subdirectories of C:\Program Files\AVAST Software\Avast. I have CRT, INF and iplugins folders.
- all subdirectories of C:\Documents and Settings\All Users\Application Data\AVAST Software\Avast
- CCleaner shows emergency update scheduled and only HKCU:Run and HKLM:Run. No RunOnce.
- AutoRuns shows avast! Emergency Update job scheduled
- Accessories > SystemTools > Scheduled task nothing here as you mentioned is hidden
Nothing any of those places.

So where is it and why do you and others expect it's scheduled and will it run at reboot or ever?

[DavidR]

Well if it was blocked, you have to find the source of the blocking.  Until the blocking of running of this uniquely named file, you essentially have an emergency update pending.

You are likely to keep getting the creation of the uniquely named file and new RunOnce entry by the AvastEmUpdate.exe file when it is run by the Scheduled Task when it checks to see if there is an emergency update available.

The RunOnce entry won't be there when you check if it has run (and been blocked), the RunOnce entry will have gone.

I don't know if you have been following other such topics, but generally after I know of an emergency update being available (WinPatrol notifying me of a new RunOnce entry being created) I reboot then. When notified I checked the Startup programs in Winpatrol it shows the new created entry. The RunOnce entry would then trigger the running of the uniquely named file to check/install any emergency update when you next reboot.

I find these locations a little strange as normally I would expect to see them in the C:\Program Files\AVAST Software\Avast\setup\emupdate sub folder - or if in the C:\Program Files\AVAST Software\Avast\setup\ folder then normally it would be a sub-folder name and that would contain the executable.

C:\Program Files\AVAST Software\Avast\setup\4598e7e2-f750-42ab-8939-5ad4b0827ae8.exe
C:\Program Files\AVAST Software\Avast\Setup\37b51beb-c180-47d9-9868-7ebdc6ae2d8d.exe

The real problem is finding what is responsible for the blocking of the executable when run on the next reboot. Usual suspects would be, your firewall (?) or other security based software that monitors/blocks new startup entries.

[MikeBCda]

Slightly off-topic, but germane to the "poor housekeeping" relative to these files ...

My Emupdate folder has 13 entries in it, the most recent being from late March (28th?) and going back to last November.  Is it safe to manually delete these (possibly keeping the most recent, as insurance)? Or is it possible that one or more of them represents an unsuccessful update attempt?

[DavidR]

Since these file names are unique, I would say it is highly unlikely that they would ever be used twice as a new unique file name is created at the time of the RunOnce entry to run it on the next boot.

Basically I have left the last chronological file name (from 28/3/2014) and removed the rest as can be seen in the image attachment in my Reply #6 of this topic. You need to disable the avast self-defence module of course.

[cooby]

I find these locations a little strange as normally I would expect to see them in the C:\Program Files\AVAST Software\Avast\setup\emupdate sub folder - or if in the C:\Program Files\AVAST Software\Avast\setup\ folder then normally it would be a sub-folder name and that would contain the executable.

C:\Program Files\AVAST Software\Avast\setup\4598e7e2-f750-42ab-8939-5ad4b0827ae8.exe
C:\Program Files\AVAST Software\Avast\Setup\37b51beb-c180-47d9-9868-7ebdc6ae2d8d.exe

The real problem is finding what is responsible for the blocking of the executable when run on the next reboot. Usual suspects would be, your firewall (?) or other security based software that monitors/blocks new startup entries.

I know exactly why it doesn't run, and reported it several times on this forum.
My firewall's behavior section blocks new, unknown, executables, issues an alert and if I'm not watching, denies.
Alternate: System Safety Monitor (HIPS) - same action. Unless a rule exists, it alerts, and if not answered, blocks it.
Both show the same path in their logs of avastEmUpdate.exe launching avast\setup\goofyNewFileName.exe
Likely, avast doesn't get a chance then to make that \setup\emupdate directory.
Many firewalls were reported here being affected because of HIPS or Behavior - Personal Firewall, Kerio, Outpost, OnLineArmor, Comodo ...

I understand now that a reboot is needed after we see it because it's scheduled. But, as I said, nothing here seems scheduled and I certainly never see the directory avast\emupdate. WHY?
Considering this flaw of randomly named files,  am I protected, is the engine up to date or not, and how can I tell? That really was the essence of my first post.

[DavidR]

Does your firewall not ask, rather than simply block.

My Firewall - Outpost Firewall Pro - also throws up a dialogue windows for it - I allow it the problem is having intercepted it, I don't know if it subsequently runs or not.

What I have tried in the past is double clicking (running) the latest file name in the emupdate, which causes a few firewall dialogues (just one shown in dialogue window attachment).

But all in all, since this new method (creation of RunOnce and creation of uniquely named executable) has caused a lot of grief for users, it is complex. If it is going to trigger tools like WinPatrol and a users firewall (any HIPS based settings), then it causes confusion and may well result in a failure of the emergency update (not being allowed to run).

[cooby]

Does your firewall not ask, rather than simply block.

YES, it asks. But I have to see it. When I don't (screensaver, walked out ...) it's blocked automatically. Hey, that policy is to keep trojans at bay after all

My Firewall - Outpost Firewall Pro - also throws up a dialogue windows for it - I allow it the problem is having intercepted it, I don't know if it subsequently runs or not.

I suspect not. If Hake, who was concerned about this in Outpost, joins here, perhaps will tell us.
Bit of details since I was able to permit one yesterday in SSM when c010bfdb-128c-4b5f-b9a0-74bba3b79eb2.exe came in.
(1) If, in the firewall, behavior module is running, alert will look like this old one I have - FW-BehaviorAlert.jpg, and that will be followed by the connection alert, like the one from yesterday, below. Similar to yours in Outpost. Kerio, Outpost - both from my experience, behave the same.
(2) When SSM runs (and firewall behavior is not running), then SSM alerts to the application start and create process - I have no screenshot, but a typical log when I allowed yesterday - SSM-appStartAllowed.jpg
But when I'm not watching to answer, it's blocked as in this screen shot of log from before - SSM-appStartMissed.jpg.
When the goofyname.exe is allowed, SSM issues a second alert about regitry, and I allowed this of course - SSM-regAlert.jpg.
That's likely the step you mention when if blocked, it would write some value into that key to schedule, and in this instance it writes nothing.
(3) Finally, when SSM was happy, firewall took over the connection by the randomName.exe - SSM-thenFwAlert.jpg(next post), through avast proxy port when the web shield is enabled, or directly to avast server port 80 if not.

What I have tried in the past is double clicking (running) the latest file name in the emupdate,

Clearly I can't rescue things this way since those files aren't here.
I have an idea just to compare notes. Next time Outpost throws you an alert, write down few letters of the random name or screenshot it, then DENY, and then see if the file gets into your \emupdate.

But all in all, since this new method (creation of RunOnce and creation of uniquely named executable) has caused a lot of grief for users, it is complex. If it is going to trigger tools like WinPatrol and a users firewall (any HIPS based settings), then it causes confusion and may well result in a failure of the emergency update (not being allowed to run).

My concern exactly.
Some of the differences we see might depend at what point the blocks occur, or release, some stuff - such as building the scheduled task and throwing those files into its own directory. Clearly, I have no such luck. Clearly, avast developers can't know what we run. But an invariant filename sure would be a good thing.

[cooby]

last one, since 4 allowed/post