诊断自愈 MSI [英] Diagnosing self-healing MSI
问题描述
我开发的应用主要是用 VB6 编写的.
一些用户报告说，当他们启动我的应用程序时，不同的 MSI 安装程序将自动运行并尝试修复自己的安装.这通常适用于 AutoCAD，但有时也适用于其他程序.
通常每次启动应用时都会发生这种情况.
我们可以使用什么程序来诊断发生这种情况的原因?由于它是第三方安装程序在运行，我们无法了解它在做什么.>
AutoDesk 确实发布了一些关于此的信息:
但是这些并没有直接提供足够的信息.理想情况下，我希望能够完全防止我的最终用户发生这种情况，而不仅仅是告诉他们如何避免或清理.
您的安装程序正在处理 Windows Installer 知道是 AutoCad 安装一部分的目录、文件或注册表项.
首先，我会打开全局 Windows Installer 日志记录.这意味着任何 Windows Installer 活动(包括 AutoCad 的安装程序)都会写入外部日志文件(在 %temp% 中).
接下来，运行您的安装程序，然后让 AutoCad 安装程序运行.
现在转到 %temp%，您应该找到文件 MSIXXXX.LOG - 一个用于您的安装程序，一个用于 AutoCad.打开这些，您可以通过它们来确定 AutoCad MSI 找到的哪个文件或注册表项丢失或更改.
您可能会发现 WiLogUtl.exe 对此有帮助:
运气好的话，您会发现触发自动修复的目录、文件或注册表项也在您的安装程序中.如果您真的很幸运，您可以将其识别为无论如何都不应该安装的项目 - 也许您正在引用一个无论如何都会存在的系统组件，该组件受 Windows 文件保护保护.
如果没有，您将不得不使用 RegFree COM 之类的工具将文件从共享目录移至您的私有目录并减少注册表冲突.此外，如果您使用(使用)Visual C++ 运行时 MSM 来制作您的 MSI，请考虑使用 Microsoft EXE 安装程序，或者(最好)将 DLL 直接放在您的程序文件夹中，因为我发现 MSM 可以导致这种问题.
The app I work on is written mainly in VB6.
Some users report that when they start up my app a different MSI installer will automatically run and try to repair its own installation. Often this is for AutoCAD but sometimes other programs also.
Usually this occurs every time they start the app.
What is a procedure that we can use to diagnose why this occurs? Since it is a third-party's installer which is running we don't have any visibility into what it is doing.
AutoDesk does have some info published on this:
but these do not directly provide enough information. Ideally I want to be able to completely prevent this from occurring to my end users, rather than just telling them how to avoid it or clean it up.
Your installer is acting on a directory, file or registry key that Windows Installer knows is part of the AutoCad installation.
First, I would turn on global Windows Installer logging. This means that any Windows Installer activity - including AutoCad's installer - is written to an external log file (in %temp%).
Next, run your installer, and let the AutoCad installer run.
Now go to %temp% and you should find files MSIXXXX.LOG - one for your installer, one for AutoCad. Open these and you can work your way through them and identify which file or registry key the AutoCad MSI find is missing or changed.
You may find WiLogUtl.exe helpful for this:
With any luck you will identify that the directory, file or registry key triggering autorepair is also in your installer. If you're really in luck you can identify it as an item you should not be installing anyway - perhaps you are referencing a system component that would be present anyway, something protected by Windows File Protection.
If not, you will have to look at something like RegFree COM to move files out of shared directories into your private directory and reduce registry conflicts. Also, if you are using (consuming) the Visual C++ Runtime MSMs to make your MSI, consider using the Microsoft EXE installer instead or (best of all) placing the DLLs directly in your program folder, since I've found that the MSMs can cause just this sort of problem.
这篇关于诊断自愈 MSI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
