PDA

View Full Version : FeatureRemoveAll() got a pop-up error message on Windows 7



nickchiu5188
09-09-2009, 10:33 PM
It seems FeatureRemoveAll() is OK for Vista 32-bit/64-bit and WinXP 32-bit/64-bit while removing the package from Control Panel (it's supposed users install the setup program from USB or CD and don't copy the setup folder onto Desktop or disk drive); however, it is not for Windows 7 RTM. An error message will be come out during un-installation as below.

The installation source for this product is not available. Verify that the source exits and that you can access it.
C:\Windos\Installer\I6cfbb.msi

The following are the scenario:
1. Install the driver package using a USB or CD.
2. Remove the USB or CD when finish the installation.
3. Reboot the PC.
4. Remove the driver package from Control Panel.
5. You will get the similar error message above.
6. You might need to execute twice or more than twice installing/un-installing process in order to get the error if you do not find the error at the first try.

joshstechnij
09-21-2009, 06:21 PM
This behavior is caused by an issue introduced with MSI 5.0 on Windows 7 and is exposed by an existing issue with InstallScript MSI projects. If you install an InstallScript MSI project that uses transforms (for language support or otherwise), uninstall it, install it again, then try to uninstall, you will receive an error because Windows Installer deleted the transform(s) required to run the package during the second installation.

The issue with InstallScript MSI projects is resolved with InstallShield 2010. However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall.

Clue.Clueless
11-10-2009, 10:04 PM
Josh,

I'm working with INS2008 and I ran into the exact problem you described. I'm just wondering what you meant by this

"However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall."

How do I accomplish this in my installer?

In another post a user said this problem could be avoided by building the installer in custom type and that has worked for me as well. However, when I make it into a Windows Self-extractor (necessary for my purpose), the same problem appear again. Any idea why?

Thanks in advance.

joshstechnij
11-12-2009, 12:31 PM
The issue is caused by a mechanism in Windows Installer that schedules files that are locked at the end of install (such as transforms or the MSI file itself) to be cleaned up the next time any MSI package is installed. If the same MSI package is installed again, its transforms will be copied to %SystemRoot%\Installer\{ProductCode}. As a result of the files that were marked for deletion the next time an MSI is installed, the same files copied to %SystemRoot%\Installer\{ProductCode} will be deleted once the install is finished during clean-up MSI performs. As a result, the product will now be in a broken state because the install can't be run without the transform(s) originally installed with the product.

The above situation can be avoided by running another MSI package because the cleanup performed during the unrelated install will remove the transforms previously marked for clean-up. The unrelated installation must be a Windows Installer based installation to ensure MSI's clean-up process is performed. Non-MSI installations (pure InstallScript, self-extracting zip, etc.) do not invoke MSI and would therefore not allow the MSI file clean-up to run.

Note that this issue occurs only with InstallScript MSI projects in InstallShield because of a long-standing issue that resulted in a leaked handle to the MSI package opened by the InstallScript engine, causing any transforms and the MSI package to be locked at the end of the installation when MSI tries to clean up these files. Due to changes in MSI in Windows 7, this can now cause the behavior described above.

Clue.Clueless
11-12-2009, 11:20 PM
Josh,

Thanks so much for your reply.

So should I be expecting a fix patch for my IS2008? Or what do you suggest I should do for our next software release? If possbile I would still like to keep using this InstallScript MSI project which we have been using for over a year. Is building the installer in custom type my best bet? Or is there a way I can build the installer as a compressed file and still avoid this issue?

joshstechnij
11-19-2009, 12:35 PM
There are no plans to provide a fix for this issue in IS 2008.

Note that this issue does not tend to appear in typical use cases (meaning a normal user should rarely, if ever, see it) and has usually been reported as appearing in test environments where a setup is repeatedly installed and uninstalled.

You could try to block the setup from running on machines that have the MSI registry key/value set indicating it needs to clean up files left behind on a previous uninstall; however, this would then rely on looking at an undocumented registry key and would provide little benefit since getting past the block would require a user run a completely unrelated MSI based installation.

scottd72
12-22-2009, 12:06 PM
The issue with InstallScript MSI projects is resolved with InstallShield 2010. However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall.

We upgraded to Installshield 2010 and this problem still exists.

Trying to uninstall an installscript MSI on Windows 7 gives us this:

8316

joshstechnij
12-22-2009, 02:00 PM
I apologize for any misunderstanding. The root cause of this issue in InstallScript MSI projects is resolved with IS 2010, meaning if you tried the exact same repro steps with a project built in IS 2010 without ever installing a build of those projects created in IS 2009 or older, the error should no longer occur. However, if the issue was reproduced with a project built in IS 2009 or older, then migrated and built in 2010, the issue may still occur. If the old project built in an older version of InstallShield was still installed and caused the original behavior, the issue needs to be corrected on the machine before a project built with 2010 sharing the same product code will work correctly.

This is due to the issue caused with MSI 5.0 and the original issue in InstallScript MSI projects built with IS 2009 or older. Installing and then uninstalling these projects puts the machine in a state that will then cause the behavior when installing another build of an MSI that has the same product code. Either the product code of this project needs to be changed, or, as mentioned earlier, another unrelated MSI installation (i.e. an MSI package with a different product code) needs to be installed to correct the machine state before running a newer build of your installation package.