WSA blocks update of Adobe Reader

Yesterday Adobe have issued a regular quarterly update to its Reader application (10.1.3). I couldn't get successfully through the update process. The update was always aborted saying that some files cannot be accessed or something like this. I tried it repeatedly but always ended with cannot write to some files prompt. In the last attempt I tried to shut down WSA and ... the update process went successfully. So my conclusion is that some of the shields of WSA was blocking the update process.

Just to let you know in case anyone encounter the same troubles with Adobe Reader update.

P.S. I should add that all my settings (including heuristics) are default except Protected websites which are both (HTTP and HTTPS) set to maximum.

 

I had a similar problem today, however I rebooted, ran Adobe as admin and it then updated ok, without disabling WSA.

 

Yeah, you reminded me that I also had rebooted because during attempting to update Reader Windows silently updated (you know every second Wednesday of a month) and prompted me to reboot. However even after reboot I couldn't succeed, so I disabled WSA completely. Nevertheless I have to admit that I didn't try to run Reader as admin.

 

I noticed that the Reader update wants to do a EFR from temp on reboot, so if you run Cleanup in WSA (or anything else) and clear temp, it blasts that file and the update fails. This is a bad behavior on the part of Reader. Temp files that are necessary for the future should always be locked, but it doesn't do this.

 

Hi pegas,

Just to let you know I had no issues updating yesterday on Win 7 x64 it updated fine!

TH

 

Interesting results here: two Win7 x64 WSA systems processed the Adobe Reader update fine and the third system I had to reboot and rerun the same Adobe update to get it work correctly.

 

Glad I saw this thread. My first attempt to update the reader also failed. Then I started the reader again with the "run as admin" option, checked for the update and it installed without incident.

 

Thx to all who replied to this thread for their valuable feedback

Here's what Webroot's QA engineer said:
"I get a feeling that either this was a transient issue, or was not actually WSA but a coincidental solution. Transient would be, for example, if you were one of the Super-Lucky Very First people doing the update and the "Popularity" heuristics in the agent caught the files and preemptively dealt with them. Coincidental would be if, for example, CCleaner was cleaning on shutdown or startup and deleting the temp files the installer wanted to do an early file replacement with, then when you shut down Webroot, you also didn't start up an app that held the files locked so it didn't need to do a replacement."

End of story.

 

Thanks for your feedback pegas!

TH

 

Mine appears to have updated fine - could everyone let me know if they've had their problems resolved?

Thanks!