Auto-update fails to complete

[bertie97]

This doesn't seem to be the subject of any other recent threads so here goes...
Since v5.1.0.90 PL fails to complete the internal update process (Win7x64) The process reports an error & asks for a reboot.
An SFX extractor dialog appears/remains on the desktop, there is no option to re-run the file-set just exit.  (Which also means I 'must' download the package again post reboot.)
Rebooting doesn't alter the result of running the internal update routine.
I have PL set to alert me rather than fully auto-update in the background.  I then click the 'update' button.

I have assumed it is AV activity, something it previously allowed that it now no longer likes.  I have told AV to allow the update but this appears to have no effect.
But I wonder why the AV doesn't react to a manual update.  (i.e. D/L & run the setup file). 

Not a major deal, just wondering what has changed that may cause this.   

[Jeremy Collake]

There was a failure of the auto-update system in v5.1.0.80 due to a localization 'fix'. Sadly, there was no good way to correct for the error, so some users of v5.1.0.78 got stuck in a perpetual failure to fully update UNTIL they did a manual re-install. Although there could be extenuating circumstances, this is most likely the cause, and a manual install will fix it up. Even if you were able to auto update successfully, you may have gotten stuck with a failing auto-update component from that older version.

More information is here: http://processlasso.blogspot.com/2012/05/automated-update-issue-with-80-requires.html

[bertie97]

Ah ha.  Yes I recall that event.  PL did update with a bit of grumbling, but there must be something left behind as you say.
I will try a clean install & see how things develop.

Thanks for the (as always) fast response.       

[Hotrod]

I ran into a similar issue which should be mentioned. Waayyy back a long time ago when quickupdate was first introduced I had asked if there was a way to get my firewall to stop making 3 new program internet access requests. The response at the time was to make quickupdate a read only file thus it would never change and firewalls would be happy with it. I had done this on a couple of my older boxes. When version .80 came along with it's little error, those systems would never stop having an update error even after a manual update via the updater. I found that if I just went to quickupdate and took away the read only setting, then the old file would get replaced by a newer one and the problems went away after one or 2 updates. If anybody else did this, here is the fix. 

[Jeremy Collake]

Lastly, I should also add that QuickUpgrade.exe is not always replaced, which is why you can get in this situation. It is only replaced, at present, if Process Lasso itself has sufficient rights to replace it (running elevated in admin context). As an optional component, it rarely needs an actual upgrade. That is why some users were never affected by this, others affected then resolved, and others affected in perpetuity. Forcing it to be replaced in all situations is the proper fix, but this requires some definite testing on this end before being rolled out. I'm implementing it in version 6, will test, then back-port and grab any affected users. That said, it is an old problem, and I wish I would have done this sooner. I had concerns, at the time, over the possible ways in which it might fail, and thus any additional fix simply needed substantial regression testing. I am normally very cautious with stable builds, which is why this was such a mess.

[bertie97]

Ran the 'auto update' routine to 5.1.1.1 & watched what was going on a bit more precisely. 
I use Comodo http://www.comodo.com/home/internet-security/free-internet-security.php & the Sandbox feature (which can be disabled/enabled) is what has been catching the SFX install routine. 
Despite telling CIS to allow the updater to proceed, CIS still interrupts the process in such a way as to prevent the process completing.

Experimentally I manually extracted/overwrote the files into the PL dir which appears to have worked (although it obviously overwrote my ini).  Resetting my config wasn't the end of the world.   

Will just have to remember to disable the sandbox before allowing the autoupdate.

I do like the fact that the foot-print & hooks of PLs installation is streamlined enough to allow this kind of update, many progs would have just died after a partial update failure.

I think in this instance QuickUpgrade.exe has been exonerated. 

[Jeremy Collake]

Thanks for the investigation and details Bertie, helps a lot .

Ah, yes, Comodo ;p... I actually fixed at least one OTHER 'issue' with Comodo's handling of PL auto-update in this last update. There was ONE unsigned module in the package. It didn't matter much, as the whole SFX is signed, and I had kept this unsigned for reasons I won't mention. Anyway, I went ahead and signed it. I had noticed this last week during an auto-update, where Comodo paused it, and said.. "such and such is not signed, you sure about this?!?!".

[Jeremy Collake]

Note that we are unfortunate enough to have an ESET False Positive on InstallHelper.exe, which may be triggered during an auto-update. This has been reported to them, and reported on the 'shame and name' site (what some security vendors call it) that I set up last year: http://falsepositivereport.org/forum/index.php/topic,271.0.html