0

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?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
user1046647
  • 369
  • 1
  • 6
  • 18
  • How large is your installation base for this package? Just to estimate what the better approach could be for you. – Stein Åsmul Nov 10 '17 at 02:33
  • Once you test, try testing on a "new machine" that hasn't had two users run the app before - if you have one, or the registry can already be configured in a way that conceals the self-heal problem. – Stein Åsmul Nov 10 '17 at 17:51
  • Just curious, were you able to resolve this issue? – Stein Åsmul Dec 13 '17 at 16:49
  • Hello Stein, We suggested the user of our program to try your ideas like deleting the existing shortcut to program and creating a new one, but it did not work. We will try a new installation to test. Thank you for really great suggestions. – user1046647 Dec 14 '17 at 23:13

2 Answers2

0

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

PowerShell sample command

  1. 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.

  2. 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":

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Hello @Stein,Thank you very much for this very elaborate answer. I will try your suggestions tomorrow, and come back to you. No, there is no user specific string in the registry:Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\User\Program] "DB_CONNECTION_SECURITY"="MixedMode" "DB_CONNECTION_SOURCE"="remote\\sqlexpress" "DB_CONNECTION_DATABASE"="Program" "DB_CONNECTION_PROVIDER"="SQLNCLI11 – user1046647 Nov 10 '17 at 01:29
  • Hello Stein, where can I place my msi file so you can look at it to find the "keep reinstalling itself" problem I mentioned above. I need to get in touch with you to resolve the problem. – user1046647 Jan 30 '19 at 02:59
0

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.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • I believe self-repair will only ensue if the registry key path is actually **missing**, it won't repair if the value of the path is just **different**? As such it might be possible to stop this self-repair by ensuring the default key path remains in the registry after you have added your custom one? Just a thought. For certain COM registry paths I think self-repair can still occur if the path is present but with a wrong value - but I haven't tested this in great detail. I am always trying the easiest practical fixes. – Stein Åsmul Nov 09 '17 at 19:54
  • @stein: I've added more info to my answer, but the point is still that a repair that cascades up to the feature will repair the entire feature and will rewrite altered registry entries. I have confirmed this by altering registry data and right-clicking to repair the MSI, a consequence of a REINSTALLMODE including "m". – PhilDW Nov 09 '17 at 20:36
  • Yes, good point. **Manual repair** is a legendary source of reset user data, such as license keys - **an MSI anti-pattern**? **Self-repair** will also overwrite changed keys once it runs, but we may be able to prevent it from running by using a **non-advertised shortcut** to launch the app or by manually updating the registry setting the broken key path manually (via logon script or some other means). But self-repair could also be triggered by other causes as you say, and then the headache is back on. Btw, Is there a way to specify a custom REINSTALLMODE for self-repair? (I haven't tried). – Stein Åsmul Nov 10 '17 at 02:27
  • Let's check with the OP how large his distribution really is - could be one machine for all we know. He could use a transform to prevent the problem in the first place for fresh installs. I haven't hacked the registry much to unregister installed components, I am not sure if you change only the cached MSI or also the component registration in the registry (I guess both). Ugly hacks that I don't want to use. So: 1) transform fix during first install, 2) launch via non-advertised shortcut, 3) manual patch of registry key path, 4) hack of the installed product component, any further options? – Stein Åsmul Nov 10 '17 at 02:38