>>The main.prg does have a code that creates an object based on the ActiveX control. But if the control is not found or not installed, the main.prg does not know how to deal with it.
>>Note that this case is a very rare instance. Most customers run the SETUP.EXE only one time and after that they forget about it.
>>Please note that the ActiveX control is installed on the desktop, not on the server. So each user has to run the SETUP.EXE one time.
>>I think what happens is that the server has something that "attached" the setup.exe to the main application .exe. So, when the main application starts, it also starts the setup.exe. Even though there is nothing wrong with the activex control on the desktop. Because I can't imaging that more than one desktops had the ActiveX control damaged or uninstalled. It is that the application .exe starts both.
>>I am still waiting for the customer when we can have a GoToMeeting so that I can view the problem and investigate it.
>
>No, it's the local comp and Installer-hell. Close as Dragan says. There is an odd lot of installers like Inno out there fiddling files into the system while ignoring Microsofts way to deal with it. If you like to know how MS expects it, send me a keg of beer.
>The reg storing it, the msi database providing it and the MS Installer system is sophisticated and reliable and keeps the system stable. If there would not be those with the cheap installers and those installing code in user data space.
>
>Note, this is not only your way pushing code to the comp, it could happen with any other odd installer running on the comp too.
>
>Anyway, to solve the problem you need to know what the system is searching.
>Possibly set up a VM, and run your Installer while running Process Monitor. This will show you what goes written to the comp, so you can search what is missing.
>
>Also you might use brute force, uninstall your ActiveX (If this is provided, often the cheap Innos are just a write only) and reinstall. Again, test on a VM.
>
>Possibly you find msi files in the Inno while tracing the install process, extract them and run them to uninstall on command line.
>

>msiexec.exe /x "c:\filename.msi"
>

>Reinstall
>
>The good on a msi is, the internal database holds the info for info install as for uninstall.

Thank you for all your suggestions.