Problem Solving

If your script is not working, here are some ideas for identifying the problem.

Verify that the Update Script file has been saved in ANSI, not Unicode format
The Web Update Wizard requires the update script files to be in ANSI text format. Your script will fail if it is saved in a Unicode format.
Turn on Verbose Logging

You can get the Web Update Wizard service to log virtually every operation it does, which may help to identify the cause of the problem.  When verbose logging is on the WebUpdateSvc4.log file can grow quite quickly, so you should only use it in a test environment or for helping specific customers.  See Verbose Logging to learn how to enable/disable verbose logging.

Can Internet Explorer access the Internet?

The Web Update Wizard uses Internet Explorer's components and settings to access the internet.  Therefore Internet Explorer (5.5 or later) must be configured to be able to access the internet, through your proxy server if relevant, in order for the Web Update Wizard to be able to work.

Even if the client machine uses Firefox only, Windows Internet Options must be correctly configured, either through Control Panel or through IE's Internet Options dialogs.

Check Proxy Server Settings

Check that the Internet Explorer proxy server settings are correct. Also check the proxy override string (proxy settings -> 'Exceptions'). We have found that Internet Explorer will allow syntactically incorrect override strings to be entered, either through the visual interface or by policy scripts which write directly to the registry. In addition, we have found that IE may work with a syntactically incorrect exceptions list, where the Web Update Wizard passes it through to the wininet libraries and fails. You can check the proxy override string at the following registry location:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride

See also: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/ierk/Ch13_d.mspx?mfr=true for more information on proxy override strings.

Is Your Web Server Correctly Configured?
We do not recommend using Windows Integrated Authentication (formerly known as 'NTLM') to store your update scripts or update files on your server behind a password protected folder. Although the client machine hosting the Web Update Wizard will be a Windows machine capable of authenticating with a Windows Integrated Authentication host, it may connect through a non-Windows proxy server. If you are getting an error code 12152 from the Web Update Wizard then this is the most likely cause. Change to 'Basic Authentication' and the error will disappear.
Is the Web Update Wizard installed correctly?
First, check that the Web Update Wizard has been correctly installed.  The easiest way to validate that the installation is working is to run the Web Update Wizard "Hello World" example.

"Hello World" uses wuw4.dll and either WebUpdateSvc4.exe running as a Windows Service (if you are running on Windows NT or later) or as a Windows executable (if you are running Windows 9x).  If the test application updates successfully, your installation is correct.

To test WebUpdateSvc4.exe in scenarios where you do not wish to deploy it as a Windows Service you should open a command prompt in the folder which contains WebUpdateSvc4.exe and issue the following command:

WebUpdateSvc http://www.dataper.demon.co.uk/wuwdemo.txt

This command will launch the Web Update Wizard and download "Hello World" V2 into the same folder as WebUpdateSvc4.exe.

Is your Application Correctly Calling the Web Update Wizard?
Please refer to the examples in the "Example of the Web Update Wizard in Action" help topic.  We have tested the Web Update Wizard in C++, C#, Visual Basic and Visual Basic for Applications projects and verified that it works correctly.

If you are using wuw4.dll to choose whether to use the Web Update Wizard service if the os is Windows NT or later or WebUpdateSvc4.exe as a standard Windows application if it is Windows 98 then any development language / IDE capable of calling a Windows DLL should work.  Remember to convert to MBCS if your application is Unicode based, using the WideCharToMultiByte() Windows API function.

If you are calling WebUpdateSvc4.exe or WuWstub.exe directly then check the syntax for the ShellExecute() API function.

Note that if the Web Update Wizard cannot download the specified server script file, for whatever reason, it makes the assumption that the user is not connected to the internet and silently finishes.  It does not show any error messages.  Therefore, if your web server logs show that the Web Update Wizard is NOT reading your script file but you ARE connected to the internet then the URL of the server script file is probably misspelled, or there is a security / firewall issue which is preventing the Web Update Wizard from downloading the script file using the standard http protocol.  In this case, try typing the URL into the address bar of Internet Explorer.  If this works but it fails with the Web Update Wizard then the likelihood is that that the firewall is blocking the Web Update Wizard or the URL has been misspelled.

If the Web Update Wizard IS successfully downloading your server script file then the problem is with your script.
Script File Issues
If you have verified that the Web Update Wizard is correctly installed and that your application is correctly calling the Web Update Wizard then there is a problem with your script.  Here are some suggestions:
  1. Check the syntax of each keyword line against the keyword reference examples in this help file.  Note that keywords ARE case-sensitive.
  2. If the script is unable to download a file needed for the update, check you have a leading '/' character in your Filename or Zipfile keyword line or that you have specified the full URL, including the "http://" part.
  3. If the script is unable to download a file needed for the update, can you download it by typing the URL into the address bar of Internet Explorer?  If not, perhaps you have misspelled the URL, not uploaded the correct file or there is a security issue on your server which is preventing the Web Update Wizard getting at the file.
  4. Check the WebUpdateSvc4.log, which is maintained by the Web Update Wizard service as it runs.  You will find this file in the same folder as WebUpdateSvc4.exe (normally the Windows\System32 folder).  Check for error messages and that the log conforms the steps you expect from your script have been completed.
  5. If your ExecBefore or ExecAfter commands are not working correctly, ensure that you use quotation marks where the path is or expands to a long filename.
  6. Start with a simple script section and add to it one line at a time.  Test on each added line.
  7. Ensure your test environment is set up correctly - i.e. you start with the correct versions of files, folder contents etc..  If you see inconsistent behaviour from the Web Update Wizard between tests then this is the most likely cause.
If you require support, the easiest way we can help you is if you allow us to run your script from our end.  Please ask your web server administrator to provide a secure login for us, and we will happily run your script through and endeavour to locate the problems.  If you would rather not take advantage of this option, then please, please provide as much detail about the problem as possible: