At each login the program tries to configure insta

Question

After a program was installed by an admin user, different users with no admin rights experience the following problem with their logins to the same computer.

At the installation of the program by an admin user, a generic connection information to a SQL database is written to a key in HKEY_LOCAL_MACHINE registry once (eg. (local)\sqlexpress). Then this information in the registry is manually modified by the admin for the relevant database connection information (eg. Remote_location\sqlexpress). So this information is machine specific, not user specific so that the program will work and fetch the data from the database for each user.

After the installation, several users (non-admin) log in to the computer to run the program:

1. User 1 logs in and the program works fine, it accesses the database. Then logs out and logs back in again, and the program works fine the next time.

2. Then user 2 logs in and starts the program. A message box pops up and it says “Please wait while Windows configures the Program” and it fails to connect to the database because the re-configuration has overwritten the database connection with the generic database connection data in the registry, so that the program cannot find database.

3. So we import the database settings to the registry and restart the program and it connects fine to the database. The user logs out and logs back in and the program works.

4. Then user 1 logs back in and the program does not work with the same message “Please wait while Windows configures the Program” even though it was already working and running previously with user 1.

It seems the program will only work for one user! How can we resolve this? Why is Windows trying to re-install the program each time a different user tries to login although the information for the program to connect to the database is in the common machine location in the registry?

Answer 1

I have added some tags to the question, most notably for sql-server-express.

Chances are users familiar with this tool will know outright what the problem really is.

---

Quick approach (preferred, do try this):

Try to manually create a shortcut on the user's desktop to launch the application in question. Do so for both users - and don't launch the pre-existing shortcut to the application (it will trigger the repair operation we are trying to avoid).

There is a chance this will eliminate the whole problem in a fashion that is acceptable. However, there is one question: is there anything user-specific about the SQL connection string? Does it contain a user name that should change from user to user? Can we see the actual connection string?

What you are seeing is most likely a Windows Installer self-repair issue. They can be quite involved to fix reliably. There is almost certainly a rather nasty error in the deployment package that triggers this problem.

---

Step-by-step approach (for MSI package debugging):

Self-repair is complicated, I think a step-by-step debugging approach might be more effective than a comprehensive explanation:

1. Find the trigger of the self-repair as described here: Windows Installer launches unexpectedly, for no obvious reason.

2. Make note of the GUID that follows: "Detection of product" in the event log as described in the article above. Sample GUID: {A54DCC30-E1EA-4912-A7F9-6C5A3AF1FB3A} (for IIS 10.0 Express - just a sample, your GUID will be different obviously).

3. Now run the following PowerShell command to determine what the product name is for the product code you found in the event log, and to find the local cache MSI package that ran the original install. Replace the GUID below with your GUID (to launch PowerShell: hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK or hit enter). The IdentifyingNumber is WMI's way to refer to a product code, so put your own product GUID in that location.

gwmi -Query "SELECT Name,LocalPackage FROM Win32_Product WHERE
IdentifyingNumber='{A54DCC30-E1EA-4912-A7F9-6C5A3AF1FB3A}'" | Format-Table Name,
LocalPackage

4. Preferred option: copy the file specified by "LocalPackage" and upload it somewhere where we can access it and let us know. There is an error in the package that needs to be sorted out (might not be easy). Don't touch anything inside %SystemDrive%\Windows\Installer\*.* - this is a "super hidden" folder that is not to be messed with at all. Only read-only actions in there. Very important.

5. Alternatively: get hold of a tool to view MSI files and do the checking yourself. It requires some MSI knowledge.

   • A full description of some MSI tools and their different merits: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc (overkill imho).
   • If you have Visual Studio installed, your fastest bet is probably to install Orca (MS SDK tool). Just search for Orca-x86_en-us.msi and install it - this is Microsoft's own, official MSI viewer and editor. After install you can find Orca in the start menu.
   • If you don't have Visual Studio installed, your fastest bet might be to try Super Orca (it is simple to use, but not extensively tested by me). It is a free (last time I checked) third party Orca alternative.

---

Windows Installer Self-Repair

Most likely you are seeing a Windows Installer self-repair. This occurs when the system has detected that an installation is incomplete in one way or another. In many cases the problem goes away if you let the installer complete its "repair", but in some cases there is an error in the installer package itself that causes problems along the lines of what you describe.

This is a complicated topic, and I have described how to debug self-repair issues many times, most recently here: some computers, the "Windows Installer" is retrieved again from the C # program that was loaded when the program was run.

For future reference I include some links on the topic of Windows Installer self-repair or "resiliency":

• Comprehensive explanation of self-repair, verbose and comprehensive: How can I determine what causes repeated Windows Installer self-repair?
• Solution focused description of self-repair, attempting to find real-world solutions: What do I do when launching an application triggers repeating, endless Windows Installer self-repair?
• Self-repair issues for developers, avoiding the problem in the first place: How do I avoid triggering MSI self-repair with my WiX / MSI package? (perhaps try this one too, should be a quick read and written specifically for developers).

Answer 2

Basically you cannot install a KeyPath registry item that is going to be changed by the user, for the simple reason that Windows Installer will believe it is broken and repair it.

The simplest cure is to give that component (in your WiX) a null component ID. As the documentation her says, under ComponentId:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx

a component with a null id is not registered and not subject to repair.

You should also verify what the actual missing component is by looking at the Windows Event log, Application, and look for MsiInstaller entries that will refer to the broken or missing component. There might really be another component that appears to be broken, such as another file or registry entry. If this is the case then the repair of the HKLM registry item could be a downstream effect because when a component is repaired Windows will repair and reinstall the entire feature, and that could include the HKLM entry. Either way, it is not safe to have an HKLM entry (registered with MSI) that can be altered because there are other scenarios (such as repair from Programs&Features or right click the MSI file) that could rewrite the registry entry. However the main point is that a repair will replace that registry entry.