Updated: 3:50pm — It gets worse — see below!
Have you ever restarted Windows (e.g. after installing Windows updates) and then been presented with the following dialog:
And of course, once you click that Install button, you eventually end up with the following:
(For the pedantic reader, yes, I captured different versions of Adobe Reader Updater on different machines. I’ve had to deal with this on 3 machines so far today. Get over it!)
Here’s why Adobe Reader needs to restart, even if you have nothing apparently running: the installer does not shut down the background processes AdobeARM.exe and reader_sl.exe (and possibly others).
For example on my Windows 7 x64 test machine, in Event Viewer, you can see the following events.
 |
|
Product: Adobe Reader 9.5.2. The file C:\Program Files (x86)\Adobe\Reader 9.0\Reader\reader_sl.exe is being used by the following process: Name: reader_sl , Id 3084.
|
 |
| Product: Adobe Reader 9.5.2. The file C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\AdobeARM.exe is being used by the following process: Name: AdobeARM , Id 3096. |
Both these processes are part of Adobe Reader, and they should be shut down by the installer. But the updater does not do this. So, you are forced to restart. This happens even if you don’t open your web browser or any other applications!
So before clicking that fateful Install button, go and kill those Adobe processes hanging around so you can avoid that restart. Also, you will need to close your web browser(s), Office applications, and anything else that you can think of that may also be involved. It’s a pain, but it’s still better than restarting.
Update: Killing AdobeARM.exe at the wrong time is a bit of an issue. Because AdobeARM.exe presents the front end to the updater! This means that if you kill AdobeARM.exe, the update dialog also disappears. The tricky fix then, is to kill AdobeARM.exe just after clicking the Install button. You get no feedback on the install, but you can see msiexec.exe (up to 3 instances during the install) running in Task Manager or Process Explorer. When it finishes, two of those will close down (the last instance hangs around for a while). It will usually leave a happy message in the Event Log.
A little extra rant? How poor is that design? Pushing updates for the updater in such a way that it forces a restart… A little bit of forethought could have avoided that one, Adobe.
Adobe has a preview handler which may have already been loaded into Explorer.
As a consequence, you may need to kill explorer.exe (that’s not just closing Explorer windows). This applies to any application which might have used a file dialog too.
If the update is a security update, restarting is the only way you can guarantee you won’t be exploited with a currently running not-yet-updated Adobe Reader component.
On the other hand, they can still try harder by e.g. making their libraries hotpatchable.
Paulo, thanks for the comment. You are correct, if Windows Installer reports that a restart is required, then you should restart to ensure that the file is updated. The fact that Windows Installer did not request a restart tells me that the files were correctly updated when following this procedure.
In this instance, as I wrote, the problem was that the files in use were loaded by the updater itself, not by Explorer: it occurs before any Explorer windows apart from the Taskbar were loaded.