在每次登录时，程序都会尝试在HKEY_LOCAL_MACHINE注册表

Question

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

在管理员用户安装程序时，SQL数据库的通用连接信息将被写入HKEY_LOCAL_MACHINE注册表中的一次键（例如(local)\sqlexpress）。然后，管理员手动修改注册表中的此信息以获取相关的数据库连接信息（例如Remote_location\sqlexpress）。因此，此信息是特定于机器的，而不是特定于用户的，因此程序将工作并从每个用户的数据库中获取数据。

安装完成后，多个用户（非管理员）登录计算机运行程序：

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

2. 然后用户2登录并启动该程序。弹出一个消息框，显示“请等待Windows配置程序”并且无法连接到数据库，因为重新配置已覆盖数据库连接与注册表中的通用数据库连接数据，因此程序无法找数据库。

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

4. 然后用户1重新登录并且程序无法使用相同的消息“请等待Windows配置程序”，即使它已经在以前用户1工作并运行。

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

Answer 1

  

我已经为问题添加了一些标记，最值得注意的是   的 SQL服务器快车

     

有可能是熟悉此工具的用户   直截了当地知道问题究竟是什么。

快速方法（首选，请尝试此操作）：

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

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

您看到的很可能是Windows Installer自修复问题。他们可以非常积极地进行可靠的修复。几乎可以肯定，部署包中存在一个相当讨厌的错误，会触发此问题。

逐步方法（用于MSI包调试）：

自我修复很复杂，我认为逐步调试方法可能比全面解释更有效：

1. 按照此处所述找到自我修复的触发器：Windows Installer launches unexpectedly, for no obvious reason.

2. 记下下面的GUID：＆＃34; 产品检测＆＃34;在上面的文章中描述的事件日志中。示例GUID：{A54DCC30-E1EA-4912-A7F9-6C5A3AF1FB3A}（对于IIS 10.0 Express - 只是一个示例，您的GUID显然会有所不同）。

3. 现在运行以下PowerShell命令以确定在事件日志中找到的产品代码的产品名称，以及查找运行原始安装的本地缓存MSI包。 使用您的GUID替换下面的GUID （要启动PowerShell：按住Windows键，点击R，释放Windows键，输入＆＃34; powershell＆＃34;然后按确定或点击进入）。 IdentifyingNumber是WMI引用产品代码的方式，因此请将您自己的产品GUID放在该位置。

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



1. 首选项：复制＆＃34; LocalPackage＆＃34;指定的文件。并将其上传到我们可以访问它的地方并告诉我们。包中有一个错误需要整理（可能不容易）。不要触摸%SystemDrive%\Windows\Installer\*.*内的任何内容 - 这是一个超级隐藏的＆＃34;根本不要搞乱的文件夹。只有那里的只读动作。非常重要。

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

   • 一些MSI工具及其不同优点的完整描述：What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc（overkill imho）。
   • 如果您安装了Visual Studio，您最快的选择可能是安装Orca（MS SDK工具）。只需搜索Orca-x86_en-us.msi并安装它 - 这是微软自己的官方MSI查看器和编辑器。安装完成后，您可以在开始菜单中找到Orca。
   • 如果您没有安装Visual Studio，最快的选择可能是试用Super Orca（它使用起来很简单，但我没有经过广泛的测试）。这是一个免费的（我最后一次检查）第三方Orca替代品。

Windows Installer自我修复

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

这是一个复杂的主题，我已经描述了如何多次调试自修复问题，最近这里： some computers, the "Windows Installer" is retrieved again from the C # program that was loaded when the program was run

为了将来参考，我提供了一些关于Windows Installer自我修复或＆＃34;弹性＆＃34;的主题的链接：

• 自我修复的综合解释，详细和全面：How can I determine what causes repeated Windows Installer self-repair?
• 解决方案重点描述自我修复，尝试寻找真实世界的解决方案：What do I do when launching an application triggers repeating, endless Windows Installer self-repair?
• 开发人员的自我修复问题，首先避免问题：How do I avoid triggering MSI self-repair with my WiX / MSI package?（或许也尝试这个问题，应该快速阅读， 专为开发人员编写）。

Answer 2

基本上，您无法安装将由用户更改的KeyPath注册表项，原因很简单，Windows Installer会认为它已损坏并进行修复。

最简单的方法是给该组件（在您的WiX中）一个空组件ID。正如她所说的文档，在ComponentId下：

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

具有空id的组件未注册且无需修复。

您还应该通过查看Windows事件日志Application来验证实际缺少的组件是什么，并查找将引用损坏或丢失组件的MsiInstaller条目。可能确实有另一个组件似乎被破坏，例如另一个文件或注册表项。如果是这种情况，那么HKLM注册表项的修复可能是下游效应，因为当修复组件时，Windows将修复并重新安装整个功能，其中可能包括HKLM条目。无论哪种方式，HKLM条目（在MSI注册）都可以更改是不安全的，因为还有其他方案（例如修复程序和功能或右键单击MSI文件）可能会重写注册表项。但重点是修复将替换该注册表项。