Windows Installer修补程序失败-在执行第一个操作并重置安装过程后，“执行序列"停止 [英] Windows installer patch failure - Execute Sequence stops after first action and install process resets
问题描述
我在几个客户站点看到我们补丁之一的异常散发.最终的错误代码是1648(找不到补丁程序的有效序列)，这是由于尝试从补丁程序转换之一读取摘要信息流时发生错误2219(无效的安装程序数据库格式)而发生的.但是我怀疑这只是早期的静默错误的副作用.我们的补丁程序全部使用MinorUpdateTargetRTM属性，因此实际上没有什么可排序的，因为任何先前安装的补丁程序都将自动被取代.我们的客户通常使用几百台几乎完全相同的笔记本电脑，并且大多数人都已经安装了此更新.在大多数情况下，只有一台设备无法更新.
I am seeing an unusual sporadic failure of one of our patches at several customer sites. The final error code is 1648 (No valid sequence could be found for the set of patches), which is occurring because error 2219 (Invalid Installer database format) occurs when attempting to read the summary information stream from one of the patch transforms. But I suspect this is only a side effect of an earlier silent error. Our patches all use the MinorUpdateTargetRTM property so there is really nothing to sequence, as any previously installed patched are automatically superseded. Our customers typically operate several hundred nearly identical laptops, and most have installed this update just fine. In most cases only one device is failing to update.
日志的关键部分在下面.初始化已完成，Windows Installer服务器进程开始执行执行序列.最后一个正常的日志条目是正在执行的操作:ISSetupFilesExtract". ISSetupFilesExtract是执行序列中的第一个动作.暂停了三分钟，然后整个安装似乎以某种方式重置并重新开始.下一个日志条目由客户端进程写入，通常服务器进程将继续运行执行序列.在安装结束之前，我不希望在客户端进程中看到其他日志条目.我怀疑这里发生了某种灾难性的失败，但我不知道可能会是什么.只有在发生这种神秘的重置之后，SequencePatches才会失败.第一次成功完成.
The key section of the log is below. Initialization has finished and the windows installer server process starts going through the execute sequence. The last normal log entry is "Doing action: ISSetupFilesExtract". ISSetupFilesExtract is the first action in the execute sequence. There is a three minute pause, then it looks like the entire installation resets somehow and starts over. The next log entry is written by the client process, where normally the server process would continue to run the execute sequence. I would not expect to see another log entry from the client process until the very end of the installation. I suspect some kind of catastrophic failure is occurring here, but I don't know what it could be. It's only after this mysterious reset occurred that SequencePatches fails. It completed successfully the first time.
MSI (s) (C4:58) [09:28:32:565]: Doing action: INSTALL
Action start 9:28:32: INSTALL.
MSI (s) (C4:58) [09:28:32:581]: Running ExecuteSequence
MSI (s) (C4:58) [09:28:32:581]: Transforming table InstallExecuteSequence.
MSI (s) (C4:58) [09:28:32:581]: Transforming table InstallExecuteSequence.
MSI (s) (C4:58) [09:28:32:581]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038
MSI (s) (C4:58) [09:28:32:581]: Doing action: ISSetupFilesExtract
<-- What happened here?! -->
=== Verbose logging started: 7/21/2014 9:31:38 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\MyCompany\Pwhc\Apps\AplPch.exe ===
MSI (c) (44:50) [09:31:38:192]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
我的问题是，有谁知道会导致安装过程像这样重置"的原因，我对此有什么办法吗?就像我说的那样，此修补程序通常有99％的时间安装.可以使用来自故障机器的完整日志: https://docs.google.com/documentation /d/1LK6HdIcetKOGqFbi5nGKAuDolvhZ3PcLxzJHv2wNDsQ/pub . 谢谢.
My question is, does anyone know what could be causing the install process to "reset" like this, and is there anything I can do about it? As I said, this patch installs normally 99% of the time. The full log from a failed machine is available: https://docs.google.com/document/d/1LK6HdIcetKOGqFbi5nGKAuDolvhZ3PcLxzJHv2wNDsQ/pub. Thanks.
回复评论的其他信息:
我们的产品使用MSI来发布Service Pack，使用补丁来发布点.每个修补程序都是累积性的，并使用MinorUpdateTargetRTM属性取代所有先前的修补程序.它们主要用于更新应用程序文件.我们总是包含整个文件以提高可靠性，并且不使用位级别的补丁程序.基本MSI为46 MB，包含1778个文件(这是一个复杂的企业产品).失败的补丁很大，只有57 MB.它添加了240个新文件，并更新了413个现有文件.
Our product uses MSIs for service pack releases and patches for point releases. Each patch is cumulative and supersedes all previous ones with the MinorUpdateTargetRTM property. They are used primarily to update application files. We always include whole files to improve reliability and do not use bit level patches. The base MSI is 46 MB and contains 1778 files (this is a complex enterprise product). The patch that's failing is quite large, 57 MB. It adds 240 new files and updates 413 existing files.
推荐答案
听起来确实在有效地使用补丁，但是您肯定违反了我的补丁的第一条规则:它应该小于基础MSI .
It really sounds like you are using patches effectively, but you are definitely breaking my number one rule for a patch: it should be smaller than its base MSI.
原因很简单，很简单，补丁只是用于已经生效的更新的交付机制.因此，这只是一个比原始设置本身更复杂且更容易出错的容器，并且当其大小超过原始MSI时，根本没有明显的理由使用该补丁吗?您可以直接运行完整的安装程序，而无需修改?实际上，您应该在出现问题的系统上进行尝试.
The reason is plain and simply that a patch is just a delivery mechanism for an update that is already working. As such it is just a container that is more complicated and error prone than the original setup itself, and when its size exceeds the original MSI there is no obvious reason to use the patch at all? You can just run the full setup without modification? In fact you should try exactly that on the systems where the problem occurs.
也许我错过了一些重要的事情?也许安装速度更快?编写得当的次要升级，或者是不会卸载并重新安装但仅注销旧版本(RemoveExistingProducts的最新排序)的主要升级，应该与之同样快.
Maybe I am missing something important? Perhaps it installs faster? A well authored minor upgrade, or a major upgrade that doesn't uninstall and reinstall but just unregisters the older version (late sequencing for RemoveExistingProducts) should be just as fast.
尽管有多年的经验和部署专业知识，但我不是补丁专家.我会积极尝试减少补丁的使用，因为这通常会带来更多麻烦，而不是值得的.但是这是发布了一些我的补丁经验的帖子.
Despite years of experience and deployment expertise, I am no patching expert. I actively try to minimize patch use, since it is generally more trouble than it is worth. But here is a post with some of my patching experiences.
对于这似乎根本没有答案，我深表歉意，但是我觉得这是有效的输入，因为您的补丁程序在57MB的空间上似乎是不必要的，并且您肯定已经有了解决方法:完整的更新MSI.
I apologize if this seems like no answer at all, but I feel this is a valid input since your patch seems so unnecessary at 57MB, and you are bound to have a workaround already: the full update MSI.
这篇关于Windows Installer修补程序失败-在执行第一个操作并重置安装过程后，“执行序列"停止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
