诊断自我修复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 File Protection保护.
如果没有，则必须查看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屋！
