Web Update Sometimes Fails


Using webupdate (and updatebuilder) to package regular updates of an application.Its a great product and most of the time it works well. I have a simple update where usually 2 or 3 files are downloaded from our Internet site (usually only 1 CAB file for application update). Clients are using various PCs and servers from Win 7 through Win 10 and Server 2008R2

Occasionally users report that they need to run the update multiple times (without success) and have to wait for the next update.

I have a situation with our current update where it will not work properly on a Windows 2008R2 server (it has in the past on this machine). The program identifies that the update is required and appears to go through the motions of download the CAB file and the help file, but when it restarts the old version of the program is still running.

This is the only information in the log file:
03/05/2016 15:19:09 : [000] UPD has EXE restarted
10/05/2016 22:58:24 : [000] UPD has EXE restarted
11/05/2016 10:49:10 : [000] UPD has EXE restarted
12/05/2016 17:31:29 : [000] UPD has EXE restarted
12/05/2016 17:33:21 : [000] UPD has EXE restarted
12/05/2016 17:37:48 : [000] UPD has EXE restarted
12/05/2016 17:44:14 : [000] UPD has EXE restarted
12/05/2016 19:31:48 : [000] UPD has EXE restarted
12/05/2016 19:41:39 : [000] UPD has EXE restarted
12/05/2016 19:59:08 : [000] UPD has EXE restarted
12/05/2016 20:03:04 : [000] UPD has EXE restarted
12/05/2016 20:29:20 : [000] UPD has EXE restarted
12/05/2016 20:32:03 : [000] UPD has EXE restarted
12/05/2016 21:02:33 : [000] UPD has EXE restarted
12/05/2016 21:05:31 : [000] UPD has EXE restarted
12/05/2016 21:08:40 : [000] UPD has EXE restarted
12/05/2016 22:36:52 : [000] UPD has EXE restarted

These are multiple attempts at running the update.

My INF file is simple (I have masked the domain name and file names)

descr=*** IF UPDATE FAILS, RUN xxxxxxxxx "AS ADMINISTRATOR" ***
descr=Main Application
descr=Help File

One thing I did notice is that the server has some Windows updates pending installation. Could that interfere with the running of webupdate? If not, is there any other likely cause?

Thanks to anyone for assistance!

This doesn't look to be the correct (or complete) log file. 

Can you lookup the full log file. This log file seems to come from the spawned updater app only.
For the issue, are you starting WebUpdate.DoUpdate(True) to force the current dir of the EXE to the actual application EXE folder?

This was definitely the complete log file from the windows server where installation was failing.

I added true as a parameter to WebUpdateWizard1.Execute(true); (as I call this instead of WebUpdate) however this does not appear to have made any difference.

Here is the additional line added to the log file:

15/05/2016 21:21:50 : [000] UPD has EXE restarted

Further to my last post, on this server. after the download Windows does not ask me to allow the program to update the original exe. I wonder if this is relevant?

Sorry but this log file isn't complete.
Set WebUpdate.Logging = true and specify the exact log filename via WebUpdate.LogFileName as there should be much more log output in the log file.

Logging was set to true and the file was already specified as WUPDATE.LOG

I found this file in the "My Documents" library on the Windows server. I know it looks incomplete because I have seen the file on other machines where installation has been OK and it is much more verbose there.

Can you set an absolute path so there is no doubt?

Hi Bruno

Thank you very much for your prompt responses. I have had an opportunity to reboot the client's server in order to install pending Windows updates. Now our program updates as expected. So it seems that if there are pending Windows updates this may interfere with the application update process. 

Curiously, I did notice however that the webupdate log is still incomplete. This is the line added following today's successful update
16/05/2016 09:11:46 : [000] UPD has EXE restarted

Unfortunately I cannot use an absolute path for the log file name because I don't know for sure the path each customer uses to install our application.

Anyway, the immediate problem seems to be solved and if this is, in fact, caused by Windows Update then I guess that's outside the control of TMS.

Thanks again.

It's important though to get the correct log file. A log file is generated from your application where TWebUpdate is linked in and it is also generated from the spawned updater app after your application has closed. The content you see in your log file is from the spawned updater. So, for some reason either your application has WebUpdate.logging = false, has a permission issue to generate the log file or is working from a different active directory that the log file is generated elsewhere.