cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
SemmlTim
Occasional contributor

RemoveExistingProdcut leaves second Registry Key (Installshield_{ProductCode}), leading to broken Control Panel entry (Error 2318?)

Jump to solution

Hi,

Im currenty  developing a MSI InstallScript Setup. To avoid most of the problems associated with MSI, I'm only using MajorUpgrades as the upgrading procedure with RemoveExistingProduct running before InstallInitialize to have a clean environment everytime.

RemoveExistingProducts however only removes ...\Uninstall\{ProductCode} registry key from the System and leaves the \Uninstall\Installshield_{ProductCode} key.  Because of this, a broken Link remains in the Add/Remove Programms DIalog in the Control Panel

So far I've checked following:

MSI (s) (xx:xx) [xx:xx:xx:xxx]: Feature: feature1; Installed: Local; Request: Absent; Action: Absent
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Component: comp1; Installed: Local; Request: Absent; Action: Absent

  • All Components are Unregistered properly and all the correspondig registry keys are removed from ...\Installer\UserData and HKCR\Installer :

MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ActionStart(Name=ProcessComponents,Description=Updating component registration,)
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ProgressTotal(Total=x,Type=1,ByteEquivalent=24000)
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: UnregisterSharedComponentProvider(Component={GUID},ProductCode={GUID})
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ComponentUnregister(ComponentId={GUID},,BinaryType=0,)

  • All Components are Unregistered properly and all the correspondig registry keys are removed from ...\Installer\UserData and HKCR\Installer 

MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: ActionStart(Name=UnpublishFeatures,Description=Unpublishing product features,Template=Feature: [1])
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: FeatureUnpublish(Feature=feature1,,Absent=2,)
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 1402 2: UNKNOWN\Installer\Features\GUID 3: 2

  • All Files and folders are "removed" from the system (more on error 2318 later)

MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: SetTargetFolder(Folder=C:\xx\xx) 

MSI (s) (xx:xx) [xx:xx:xx:xxx]: Executing op: FileRemove(,FileName=file1.dll,,ComponentId={GUID})
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Verifying accessibility of file: file1.dll
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 2318 2:
MSI (s) (xx:xx) [xx:xx:xx:xxx]: Note: 1: 2318 2:

I'm testing those Installations in a virtual machine with full admin privilege and revert to a snapshot when I encounter that error, so this isn't caused by older installation. All my CustomActions have "NOT UPGRADINGPRODUCTCODE" in their condition and none of them is getting executed

 

When I create a new test project I don't have this problem. The only difference in the Log file are the two

  • "Note: 1: 2318 2:"

messages behind the file removal are missing. This tells me that, even when MSI is able to remove all of the files, it "thinks" it doesn't have the rights to open them.

Can anyone confirm my suspicions, has a solution or a better explanation for this behaviour?

Thanks in advance!

 

(I removed some of the data that mightbe considered sensitive.)

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
SemmlTim
Occasional contributor

Re: Problem caused by possible bug

Jump to solution

I think I might found a bug in Installshield that causes this behaviour: When you pass MSI Logfile Options with the /V Parameter AND the path to the MSI logfile contains a dot(!) WHILE your doing a MajorUpgrade operation, Installshield will keep the broken Add/Remove Programs entry in the registry. 

You can reproduct this behaviour with any setup.exe that is created from a Installscript MSI project (might affect other project types, but I didn't test them so far):

  1. Make a setup and generate two different versions (eg 1.0.0 and  2.0.0)
  2. Create a path with dots, eg. C:\path.with.dots\
  3. run the Setup with following argument

Setup.exe /V" /L*v!"""C:\path.with.dots\setup.log""""

 

This error doesn't reproduce when working with a .msi file, so it seems to be a problem with the IS Bootstrapper.

 

My current workaround will be saving those files to a path that doesn't contain dots (like C:\Windows\Temp) and copy the file back to where I want it after the installation

View solution in original post

Tags (1)
0 Kudos
1 Reply
Highlighted
SemmlTim
Occasional contributor

Re: Problem caused by possible bug

Jump to solution

I think I might found a bug in Installshield that causes this behaviour: When you pass MSI Logfile Options with the /V Parameter AND the path to the MSI logfile contains a dot(!) WHILE your doing a MajorUpgrade operation, Installshield will keep the broken Add/Remove Programs entry in the registry. 

You can reproduct this behaviour with any setup.exe that is created from a Installscript MSI project (might affect other project types, but I didn't test them so far):

  1. Make a setup and generate two different versions (eg 1.0.0 and  2.0.0)
  2. Create a path with dots, eg. C:\path.with.dots\
  3. run the Setup with following argument

Setup.exe /V" /L*v!"""C:\path.with.dots\setup.log""""

 

This error doesn't reproduce when working with a .msi file, so it seems to be a problem with the IS Bootstrapper.

 

My current workaround will be saving those files to a path that doesn't contain dots (like C:\Windows\Temp) and copy the file back to where I want it after the installation

View solution in original post

Tags (1)
0 Kudos