Hi all,
I have a problem that I have encountered before, however it was a couple of years ago now and I forget what I did to solve it.
I have a user that installed some software from CD onto his desktop as an admin.
When this user then ran the shortcut as a locked down user the application started repairing. There is a Current User registry key in the application that will get written by the advertised shortcut. There are no User Specific files present.
The repair fails when the user runs the shortcut with the following error -
"An installation package for the product XXXXX cannot be found. try the installation again using a valid copy of the installation package "XXXX.msi""
This led me to think that when the msi is repairing for the user, it is trying to repair a file, and it needs the original msi for this.
I asked the user to copy the contents of the CD to his C:\ drive and carry out the install from there.
When he does this and runs the application as a locked down user the applicaiton repairs itself and the error does not appear.
Why would this be happening?
Obviously I don't want the contents of the CD copied to the users hard drive.
Any ideas?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


For a registry-only self-repair, normally the cached copy of the original MSI (held in the %windir%\installer folder) which will be devoid of any of the original files deployed by the MSI, should still be adequate for performing the repair.

If however one or more files are required from the original source media, then Windows Installer will then try the last source from which the product was installed - in your case the CD drive which (of course) no longer has the original MSI and/or CAB file available.

If you are *sure* that no files are needed for repair, then this may point to the original cached MSI now being missing - perhaps it was deleted as part of over-zealous housekeeping (?)

Have a look in the %windir%\installer folder in Windows Explorer. The cached MSI's are given randomised names so it helps if you click View ... Choose Details .. and select "Subject" - this hopefully will then expose the product names of all the cached MSI's.

As to how you would address this, you could always update the sourcelist for the product directly in the registry. The source lists for each installed product can be found in the registry under HKEY_CLASSES_ROOT\Installer\Products\<mangled product id>

Note that the product id is 'mangled' so doesn't correlate to the original product ID of
the MSI, but within this key, there is normally a ProductName value which is user readable. If you can locate the correct key for your product, there is a subkey named SourceList and below that a subkey named "Net". The Net key will contain at least one string value named "1". The contents of this value will show the original source path. You need to add a new string value to the Net subkey named (in this case) "2" and make the contents a UNC path to a server folder that can host the original MSI copied from the CD.

There is a Windows Installer API function, MSISourceListAddSource, to make this sort of change programmatically but I don't have any sample code.


Answered 08/07/2008 by: spartacus
Black Belt

Please log in to comment
Hi Mark,
please tell us, on which application you are working.
Then please log the repair and post the portion around the error (use the code tag).
Often, things like that are caused by files without correct versioning or hashes.
Regards, Nick
Answered 08/07/2008 by: nheim
Tenth Degree Black Belt

Please log in to comment