Windows installer patch failure - Execute Sequence stops after first action and install process resets

Question

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.

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

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.

Additional info in response to comments:

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.

Answer 1

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.

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.

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.

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.