Share via

Arbitrary labels used as Primary keys must not be changed between versions

  • Article

Summary

Msi Editing tools that write auto generated references inside installer tables may cause unnecessary content to be included inside a patch. ‘Patching’ components with unchanged content may cause them to be uninstalled when the patch is removed thereby breaking the original application.

Scenario

 “I create a small patch for my product. When I selectively uninstall the patch my original product is broken. The trouble is I’m using Msi 3.x and this isn’t supposed to happen. Doesn’t Msi 3.x ‘cache’ whatever I patch so I can just roll it back when I uninstall? I have followed all the rules to the letter but can’t see where things are going wrong?”

This Is How I Can Reproduce This Behaviour

I create an installation msi for my simple single file application msiExplorer.exe. There is nothing untoward about this installation. The file goes in Program Files\msiExplorer and puts a shortcut on the desktop. The installation also creates a single registry key HKLM\Software\msiExplorer with value Text set to “A”. It installs. It works. Here’s the registry table:

egkey1 

Next, I create a new ‘upgraded’ version of this product. The only thing I change is the label in the registry column of the registry table. (Why would I want to do that!? – well just bear with me and I’ll explain below). I change the label to “RegKey2”.

regkey2 

Now I go through the patch creation process by duly creating a PCP file. In the PCP I specify the old ‘RTM’ msi and the new ‘updated’ msi – the usual routine. When I execute MsiMsp.exe it works. No errors reported. I can even load the original RTM msi database into Orca and overlay it with my new msp. It confirms that the registry table has been modified and shows me what is now included in the patch.

Regkey1Regkey2 

Notice how the actual Registry key, value and data are the same. Only the Registry column has changed.

Ok, I install RTM. It runs without problem; the registry key is duly created. I apply the patch (msiexec /p msiExplorer.msp). It installs, it runs. The Registry key looks the same – well it would wouldn’t it? At this stage it’s difficult to tell who was responsible for writing that registry value – the RTM install or the subsequent patch.

regdumpTextA

However I know the patch has been successfully applied because when I look in Add\Remove programs, there is my app and the patch correctly listed.

arpPatch1 

So everything looks good. Unfortunately the trouble starts when I decide to selectively remove MsiExplorer_Patch1 (msiexec /i msiExplorer.msi MSIPATCHREMOVE=msiexplorer.msp). The patch uninstall executes successfully, Add\Remove programs shows it has been removed and I think I’m ok.

arpPatch1Removed 

But when I look in the registry.......

 regdumpTextAgone

              .........my registry key has gone. So now you can imagine when I run my app – if it depended on this key – it’s going to fail.

Why does that happen?

The key aspect of the scenario is that the registry key with a new label ‘looks’ like a new registry resource added by the patch. When a patch is removed, the new product is restored to its view minus the patch. Additionally, the Installer processes the patch being removed for any resources that it added. It then schedules removal for those resources. Therefore, while the key with label RegKey1 became active (the verbose log file shows it being written).........

 

verboseLogAdded 

 

........... it was later deleted per label RegKey2 as part of the added resource cleanup (the last portion of the verbose log file before the end opcode). 

 

verboseLog_Removed 

So How Could You Unknowingly Get Into This Situation?

I’m using an ‘industrial strength household name Msi Editing tool’ (ISHNMET). It’s a very good product. It has a nice feature which will read a COM Server file and automatically extract the COM registration information and populate the tables. One of these tables is the registry table. It therefore populates the registry column with arbitrary labels Registry1, Registry2...etc. Here’s a mock up of how it might look:

mockupBefore

I have to rebuild my msi package every day and have automated the process. The developers submit their updated files and the tables are built by script. When the msi is built by the ISHNMET it does its trick of automatically extracting the COM information. If the developer has built some extra COM functionality into a dll the entries are inserted mid table bumping all the lower rows down. The naming algorithm just re-labels all the rows. In this example Registry4 gets bumped down a row and re-labelled as Registry5

mockupAfter 

Now when we go through our patch creation process we correctly pick up that MsiExplorer.exe component has changed but inadvertently include component ‘SomeComponent’ because the label changed! Now we are going to deliver a patch which includes the problem discussed above.

To be fair the very latest versions of ISHNMET try to minimise this scenario. However you might for example delete a registry entry and then change your mind, re-create it using the GUI and have it reappear in the registry table with a brand new label. So it probably pays to be aware of the dangers of arbitrary labels.

Does this happen anywhere else?

Exactly the same issue applies to the file table. If the ISHNMET uses arbitrary labels for the files it is adding to the file table then they are subject to the same vulnerability. Where the label in the file table is used as the keypath in the component, it is automatically changed at both reference points when re-labelling occurs. From the ISHNMET point of view this keeps the referential integrity between Component and File nice and tidy. From our point of view though, this will be picked up by MsiMsp.exe. You could finish up attempting to patch a file with an identical copy. Here is what this looks like with my simple example:

Modify the File column of the file table (Was msiExplorer.exe, now msiExplorer1.exe)

FileExample1 

 

... and modify the keypath reference in the component table....

fileExample2 

Create the patch and just to confirm it, overlay the RTM msi with the msp.

 fileExample3

Install RTM. Install the patch. Use Add\Remove programs to confirm the patch is registered

 fileExample4

You might even inspect the patch cache and notice that no copy of msiExplorer.exe has been saved.

fileExample5 

Now selectively uninstall the patch and the original msiExplorer.exe (The one in Program Files\msiExplorer) has disappeared. Try to run the shortcut and if you’re lucky the executable will be restored via install-on-demand resilience or in my case, just to prove the point, I hid the source msi so that I could see the install-on-demand dialog.

fileExmple6 

The app is broken.

This same explanation above works for the File as well – and it should be noted that you’d need to maintain the same filekey for binary delta patching to work (just look at the Patch table and you’ll know why by reviewing the primary key columns for that table)

 

Here’s the Message

The Installer’s format is a relational database. Identity is expressed by the primary key – which is why it is so crucial. An item is found in the database by searching for its primary key. That’s how transforms can know which data to modify (efficiently) and how Patchwiz can determine what has changed. It’s imperative that the primary keys are not changed between versions of the package. 

 

 

[Author: Robin Drake]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.

Comments

  • Anonymous
    March 07, 2007
    ISHNMET does have a feature that synchs the file table primary keys (but only the file table). In the releases view there is a field called Previous Package that you point at v1. I hope that it is extended in light if this fascinating article

  • Anonymous
    March 08, 2007
    The same problem (Registry table gets "corrupted") happens also with InstallShield 10.5 (and I guess it happens also in more recent versions as well). I got a confirmation from the InstallShield support team that this is a bug and it should be fixed some when in the future (However, no fix date or version provided).

  • Anonymous
    March 08, 2007
    The comment has been removed

  • Anonymous
    March 08, 2007
    The comment has been removed

  • Anonymous
    March 13, 2007
    The comment has been removed

  • Anonymous
    March 29, 2007
    hi I am not a computer guy but after I ran windows update. i could get access to my Microsoft office program(excel, word etc...) every time i click on one of the program, it bring me to a windows installer window, then it says "windows installer service could not be accessed.this occur if you are running windows in safe mode, or if the windows installer is not correctly installed" please help

  • Anonymous
    May 18, 2007
    I think HKCU related keys are present in your application that keys are searching  for source(.MSI or .EXE) in user and admin. HKCU keys move to HKLM keys.resolve this problems.

  • Anonymous
    May 18, 2007
    I think HKCU related keys are present in your application that keys are searching  for source(.MSI or .EXE) in user and admin. HKCU keys move to HKLM keys.resolve this problems.

  • Anonymous
    May 18, 2007
    I think HKCU related keys are present in your application that keys are searching  for source(.MSI or .EXE) in user and admin. HKCU keys move to HKLM keys.resolve this problems.

  • Anonymous
    May 18, 2007
    I think HKCU related keys are present in your application that keys are searching  for source(.MSI or .EXE) in user and admin. HKCU keys move to HKLM keys.resolve this problems.