每次登录时，程序都会尝试在 HKEY_LOCAL_MACHINE 注册表中配置安装参数 [英] At each login the program tries to configure installation parameters in the HKEY_LOCAL_MACHINE registry

问题描述

在管理员用户安装程序后，没有管理员权限的不同用户在登录同一台计算机时会遇到以下问题.

在管理员用户安装程序时，SQL 数据库的通用连接信息会写入 HKEY_LOCAL_MACHINE 注册表中的一个键(例如 (local)sqlexpress).然后管理员手动修改注册表中的这些信息以获得相关的数据库连接信息(例如Remote_locationsqlexpress).因此，此信息是特定于机器的，而不是特定于用户的，以便程序能够运行并为每个用户从数据库中获取数据.

安装完成后，有几个用户(非管理员)登录电脑运行程序:

1. 用户 1 登录并且程序运行良好，它访问数据库.然后注销并重新登录，程序下次运行正常.

2. 然后用户 2 登录并启动程序.弹出一个消息框，显示Windows 正在配置程序，请稍候"，并且无法连接到数据库，因为重新配置已使用注册表中的通用数据库连接数据覆盖了数据库连接，因此程序无法连接找到数据库.

3. 所以我们将数据库设置导入注册表并重新启动程序，它可以很好地连接到数据库.用户注销并重新登录，程序即可运行.

4. 然后用户 1 重新登录，该程序无法运行，并显示相同的消息Windows 正在配置程序，请稍候"，即使它之前已经与用户 1 一起工作和运行.

   莉>

该程序似乎仅适用于一位用户！我们如何解决这个问题?尽管程序连接到数据库的信息位于注册表中的公共计算机位置，但为什么每次不同的用户尝试登录时，Windows 都会尝试重新安装该程序?

解决方案

我在问题中添加了一些标签，最显着的是sql-server-express.

熟悉此工具的用户可能会彻底了解问题所在.

<小时>

快速方法(首选，试试这个):

尝试在用户桌面上手动创建快捷方式以启动相关应用程序.为两个用户都这样做 - 并且不要启动应用程序的预先存在的快捷方式(它会触发我们试图避免的修复操作).

这有可能以可接受的方式消除整个问题.但是，有一个问题:SQL 连接字符串是否有任何特定于用户的内容?它是否包含应该随用户更改的用户名?我们能看到实际的连接字符串吗?

您所看到的很可能是 Windows Installer 自我修复问题.他们可以非常参与以可靠地修复.几乎可以肯定，部署包中有一个相当严重的错误触发了这个问题.

<小时>

分步方法(用于 MSI 包调试):

自我修复很复杂，我觉得一步一步调试的方法可能比综合解释更有效:

1. 按此处所述找到自我修复的触发器:

   4. 首选选项:复制LocalPackage"指定的文件并将其上传到我们可以访问的地方并让我们知道.包中有错误需要整理(可能不容易).不要触摸 %SystemDrive%WindowsInstaller*.* 里面的任何东西——这是一个超级隐藏"的文件夹，根本不会被弄乱.只有只读操作在那里.非常重要.

   5. 或者:获取一个工具来查看 MSI 文件并自己进行检查.它需要一些 MSI 知识.

      • 对一些 MSI 工具及其不同优点的完整描述:使用什么安装产品?InstallShield、WiX、Wise、高级安装程序等(恕我直言).
      • 如果您安装了 Visual Studio，您最快的选择可能是安装 Orca(MS SDK 工具).只需搜索 Orca-x86_en-us.msi 并安装它 - 这是 Microsoft 自己的官方 MSI 查看器和编辑器.安装后，您可以在开始菜单中找到 Orca.
      • 如果您没有安装 Visual Studio，您最快的选择可能是尝试 Super Orca(使用起来很简单，但没有经过我的广泛测试).这是一个免费的(我上次检查过的)第三方 Orca 替代品.

   <小时>

   Windows 安装程序自我修复

   很可能您看到的是 Windows Installer 自我修复.当系统检测到安装以一种或另一种方式不完整时，就会发生这种情况.在许多情况下，如果您让安装程序完成其修复"，问题就会消失，但在某些情况下，安装程序包本身存在错误，会导致您描述的问题.

   这是一个复杂的话题，我已经多次描述如何调试自修复问题，最近一次在这里:一些计算机，Windows 安装程序"从程序运行时加载的 C# 程序中再次检索.

   为了将来参考，我提供了一些有关 Windows Installer 自我修复或弹性"主题的链接:

   • 自我修复的综合说明，详细和综合:如何确定导致 Windows Installer 重复自我修复的原因?
   • 针对自我修复的解决方案描述，试图找到现实世界的解决方案:当启动应用程序触发重复、无休止的 Windows Installer 自我修复时，我该怎么办?
   • 开发者自行修复问题，首先避免问题:如何避免使用我的 WiX/MSI 包触发 MSI 自我修复?(也许也试试这个，应该可以快速阅读并且专为开发人员编写).

   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_locationsqlexpress). 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?

   解决方案

   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%WindowsInstaller*.* - 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).

   这篇关于每次登录时，程序都会尝试在 HKEY_LOCAL_MACHINE 注册表中配置安装参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！