cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
CChong
Level 11 Flexeran
Level 11 Flexeran

Fails to Uninstall on Windows 7

I have written an Installshield Installer that is meant to work on XP, Vista and Windows 7.
I am dealing with all of the numerous issues sequentially.
Currently I am testing the install/uninstall on Windows 7. While the application fully uninstalls everything on XP and Vista, unfortunately it uninstalls NOTHING on Windows 7. When I say nothing I mean literally nothing. Yet the uninstall runs without failing. While I haven't installed Installshield 2010 SP1 yet, I'm not sure if this is the issue that is causing this problem.
Any ideas community? Thanks.
Labels (1)
0 Kudos
(6) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Your post isn't clear about what project type, so please include that information in a follow up post. Here are some things you can check. Does the installation remain listed in ARP? Does it matter how the uninstall is kicked off - i.e. does starting it from ARP (now Programs and Features) do one thing, whereas rerunning the initial installer file do another? Does it matter if you start the uninstall from an elevated command prompt instead of an unelevated context? If it's an MSI-based installation, does a verbose log show anything interesting?
0 Kudos
CChong
Level 11 Flexeran
Level 11 Flexeran

Hi Michael
The project type is Installshield 2010 Basic MSI.
The same thing is happening after I installed IS 2010 SP1.
My install places about 30 COM dlls in a folder c:\[CompanyName]\[ProductName]
and about 30 com dlls in a folder called c:\[CompanyName]\[COMMON]
It also creates an IIS application in the folder c:\Inetpub\WWWROOT\[CompanyName]\[ProductName]\[Application]
These folders do not get deleted. The same Install deletes them on Windows 2008 Server and XP when uninstalled.
However, the registry does get deleted on uninstall for Windows 7. And the listing is removed from ARP.
I run the uninstall as administrator with UAC at the lowest level.

Breaking news
I have found the reason, and I think its a bug in Installshield.

In the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Shared DLLS
when you install an Installshield application, any DLLs installed are given a reference count. When the install is run on Windows 7, the reference count is set to 2, and on all other operating systems it is set to 1, so therefore when an uninstall is required, because the reference count is set to 2, it is decremented to 1 which means it cannot be deleted.
The question is why is the reference count being set to 2 instead of 1 on Windows 7?
Any takers?
0 Kudos
CChong
Level 11 Flexeran
Level 11 Flexeran

Any Installshield engineers out there to answer this?
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

If it is Shared DLLs, then it's a Windows Installer issue, if it's a bug at all. Chances are if you've tested multiple versions of your installer, at some point a component rule was broken. It's also possible you may have a component rule violation within the current version of the package. It's best to test packages, especially rapidly changing ones, on machines you can revert to a clean state because of this reason. That said, you can probably also exit the problem by decrementing the share count before uninstalling the application.
0 Kudos
CChong
Level 11 Flexeran
Level 11 Flexeran

Thanks Michael,
but what I did after the uninstall was to delete all of the DLL values associated with my install from HKLM\Software\Microsoft\Windows\CurrentVersion\Shared DLLS.
On re-install, the share count was immediatly set to 2 for all dlls.
One question Michael, I take it you cannot reproduce the problem on your Windows 7 machine?
By the way no component rules were broken in my install. Anyway if they were, the problem would arise too on Windows 2008, and it does not.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

A share count of two after a first time installation is typically caused by one of the following:
- The file is being included in more than one component in the installation package (an ICE30 will be reported when validating if this is the case), breaking component rules.
- The file already exists at the target location at runtime and the Shared component attribute is set to Yes on the component that installs the file (all components created by InstallShield by default are have Shared set to Yes by default). Windows Installer will then set the share count to 2 in this case to account for the existing file and the new file that would be installed.

More information on files not being removed on uninstall can be found in the following article:
Removing Stranded Files
0 Kudos