Please wait while Windows configures <ProductName>

[yakshasa]

Our customer gets this message every time she goes into our application now. This started after she downloaded an updated EXE of our application via the web. If she puts her original cd in, it lets her in. If not, she continues to get this message. The new features added to our application via the updated exe are available once she is in the program.

Exe is installed on same machine as the original installation. Downloaded from web and pasted the exe to the existing program folder, overwriting the previous exe. Customer was logged on as the same user as in the original install.

EXE is written in VB6, machine is XP

2008/12/02

Customer rebooted and issue went away. Another customer had same issue and it also went away after rebooting, but returned after cleaning temp files.

Looks like the culprit is Axdist.exe, a now obsolete redistributable that was inadvertently carried over from InstallShield2.12 when we upgraded InstallShield versions.

Some of the registration process in Axdist.exe is not completed until the machine is restarted - which explains why rebooting helped, and, it gets clobbered anytime a user clears out their temporary files - which explains why the issue crops up again.

We intend to remove Axdist.exe from future CD updates and installations since MS advises not to run Axdist.exe on systems that have Internet Explorer 3.0 or higher installed.

The question is should we advise current users to uninstall the existing installation first, before running the CD update? Vista seems to require uninstallation of existing version automatically, XP and earlier do not.

We have numerous ISE 2.12 installations out.

If we issue issue an update of our product using ISE 2008 or 2009, will the ISE 2008/2009 install recognize that the preexisting ISE 2.12 installation is the same product?

Would there be any issues if the customer installed over the ISE 2.12 installation?

Would there be any issues if they installed over a previous ISE 2008 installation that had the reference to Axdist.exe?

Please someone respond (especially from Acresso)

[mberterm]

Some of the symptoms sound a little odd, but on the whole, this seems to be an issue of auto-repair.

If we issue issue an update of our product using ISE 2008 or 2009, will the ISE 2008/2009 install recognize that the preexisting ISE 2.12 installation is the same product?

A little hard to tell without knowing more of the root cause. However, I do not believe that ISE 2.12 (InstallShield Express version 2.12) produced an MSI based installation package so the behaviour may be more isolated to the packages produced with Express 2008 and/or Express 2009.

Is the behavior improved if the previous installations are removed (via Add/Remove Programs) before the latest package is installed? I would think that it is advisable, especially when troubleshooting, to have the customer(s) manually remove the previous installation before attempting to install with the latest package.

Would there be any issues if the customer installed over the ISE 2.12 installation?

As long as the MSI based installation package was able to sucessfully lay down the file (and then it was not removed/modified post installation) I would not expect to see an auto-repair.

Would there be any issues if they installed over a previous ISE 2008 installation that had the reference to Axdist.exe?

There could be--see some of the MS articles linked in the thread mentioned below.


For the in-depth troubleshooting, take a look at this thread which further discusses auto-repair causes/resolutions. (Microsoft seems to have moved some documentation around recently so search using the terms in each line item if the correct article doesn't come up right away.)

For a quicker look, scan these locations for the specifics regarding each repair attempt on a given machine:

• the application log in the event viewer
  
• the repair log after enabling MSI logging via a registry entry
  

Customer rebooted and issue went away. Another customer had same issue and it also went away after rebooting, but returned after cleaning temp files.

Some of the registration process in Axdist.exe is not completed until the machine is restarted - which explains why rebooting helped, and, it gets clobbered anytime a user clears out their temporary files - which explains why the issue crops up again.

Why does any portion of the installation install files to the temporary folder?

Looks like the culprit is Axdist.exe, a now obsolete redistributable that was inadvertently carried over from InstallShield2.12 when we upgraded InstallShield versions.

Has this obsolete redistributable been removed from the latest installation package? If so, is this behavior seen when the product is installed with that package?

[yakshasa]

Sincere thanks for the response:)

Axdist.exe is dated 1999 and tries to install some really outdated items related to Internet explorer 3.0.

We upgraded from InstallShield Express 2.12 to ISE 12, ISE 2008 and ISE 2009respectively, with the reference to Axdist.exe being carried over with each upgrade, unfortunately.

I think InstallShield Express 2.12 (which used a proprietary engine) would stick Axdist.exe in a temporary folder, run it, then delete it, but that behavior did not carry over in the upgrades, which apparently stuck Axdist.exe in the temporary folder but treated it as a permanent part of the installation.

We have since tested an update installation - without prior uninstallation - in which the redistributable had been removed from the latest package. The user ceased getting the behavior when the product was installed with the Axdist.exe-free package 🙂

[mberterm]

Glad to hear!