the

the

关注
发信
关注(28)粉丝(399)

每次登录时，程序都会尝试在HKEY_LOCAL_MACHINE注册表中配置安装参数

本文介绍了每次登录时，程序都会尝试在HKEY_LOCAL_MACHINE注册表中配置安装参数的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

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.

在由管理员用户安装程序时，一次将与SQL数据库的通用连接信息写入HKEY_LOCAL_MACHINE注册表中的键(例如，(local)\sqlexpress).然后，管理员会针对相关的数据库连接信息(例如Remote_location\sqlexpress)手动修改注册表中的此信息.因此，此信息是特定于计算机的，而不是特定于用户的，以便程序可以运行并为每个用户从数据库中获取数据.

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. 用户1登录并且程序运行正常，它可以访问数据库.然后注销并再次登录，该程序下次可以正常运行.

  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登录并启动程序.弹出一个消息框，提示请等待Windows配置程序"，它无法连接到数据库，因为重新配置已用注册表中的通用数据库连接数据覆盖了数据库连接，因此该程序无法查找数据库.

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.

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

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.

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

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.

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

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?

推荐答案

有机会让熟悉此工具的用户 完全知道问题出在哪里.

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

有可能以可接受的方式消除整个问题.但是，存在一个问题: SQL连接字符串是否有用户特定的内容??它是否包含应随用户而变化的用户名?我们可以看到实际的连接字符串吗?

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?

您看到的最有可能是Windows Installer自修复问题.他们可能会投入大量精力进行可靠的修复.几乎可以肯定，部署程序包中有一个相当讨厌的错误会触发此问题.

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.

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

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

  1. 按如下所述查找自我修复的触发器: Windows Installer意外启动，没有明显的原因.

请注意以下GUID:如上所述，在事件日志中显示"产品检测".样本GUID:{A54DCC30-E1EA-4912-A7F9-6C5A3AF1FB3A}(对于IIS 10.0 Express-仅是一个样本，您的GUID将会明显不同).

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

现在运行以下PowerShell命令来确定您在事件日志中找到的产品代码的产品名称是什么，并查找运行原始安装的本地缓存MSI软件包. 用GUID替换下面的GUID (要启动PowerShell:按住Windows键，点按R，释放Windows键，键入"powershell"，然后按OK或按Enter键). IdentifyingNumber是WMI引用产品代码的方式，因此请将您自己的产品GUID放在该位置.

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

  1. 首选选项:复制"LocalPackage"指定的文件，然后将其上传到我们可以访问并告知我们的位置.包中有一个错误需要解决(可能不容易).不要触摸%SystemDrive%\Windows\Installer\*.*内的任何内容-这是一个超级隐藏"文件夹，根本不要弄乱.那里只有只读动​​作.非常重要.

  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.

或者:拥有一个工具来查看MSI文件并亲自进行检查.它需要一些MSI知识.

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

  • 一些MSI工具及其优点的完整描述:(过大杀手，恕我直言).
  • 如果已安装Visual Studio，则最快的选择可能是安装Orca(MS SDK工具).只需搜索Orca-x86_en-us.msi并安装它-这是Microsoft自己的官方MSI查看器和编辑器.安装后，您可以在开始菜单中找到Orca.
  • 如果您未安装Visual Studio，则最快的选择可能是尝试超级Orca (使用简单，但没有经过我的广泛测试).这是一个免费的(我上次检查过的)第三方Orca替代产品.
  • 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自我修复

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

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.

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

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.

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

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注册表中配置安装参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

10-24 17:47
Powered by LMLPHP ©2024 the 0.005046