1

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.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
David Tarulli
  • 929
  • 1
  • 10
  • 13
  • I found Installshield buggy with regards to patching, other tools such as Wise performed better. Could you explain better what the patches are for, what they are doing, how big they are in terms of file size and number of files updated (if any) and if you include whole files or do bit level patching, etc... – Stein Åsmul Jul 24 '14 at 00:53
  • I added the requested info to my question. I don't love installshield and have experienced some bugs, but overall our MSIs and MSPs seem to be very reliable. – David Tarulli Jul 24 '14 at 15:48

1 Answers1

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.

Community
  • 1
  • 1
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • I understand and agree with what you are saying. The reason for the large patch size is because of a fixed release schedule and the need for consistency in how each type of release is packaged. Corporate politics delayed the next MSI-based service package release, but new features and bug fixes still needed to go out the door. If I had my way I would package everything as an MSI. Ironically the motivation for using patches was to minimize the size of the update packages. – David Tarulli Jul 24 '14 at 21:54
  • I do have RemoveExistingProducts sequenced between InstallExecute and InstallFinalize, so a major upgrade doesn't uninstall the old version of the product. I agree this is a good approach and a major upgrade is always going to be more reliable than patching. I received a new update today: one customer experienced the error, sucessfully uninstalled the product, but then got an error when reinstalling the MSI. I haven't been able to get any logs or additional info on this. They have likely reimaged the device so I'll have to wait for the next one. – David Tarulli Jul 24 '14 at 21:55
  • A patch can not be created unless you make a working minor or major upgrade and package it as a patch (unless you use QuickPatch which is definitely not reliable in my experience). Installing a well authored major upgrade on top of an existing install sort of "works like patching". New files are installed and others updated. When the MSI is then smaller than the patch, the patch is worthless in my opinion - it adds nothing but risk and complexity. My bet is there is something wrong with the last MSI built - this would affect both fresh and patch install since the latter is based on the former. – Stein Åsmul Jul 24 '14 at 22:48
  • I have reviewed the MSI used to create the patch in question, and it appears normal. It is built by an automated process, and comparisons to previous MSIs didn't show anything unusual. I will check again though. In my comment above about the MSI failing to reinstall after uninstalling the product, it was the old MSI from the last service pack, not the MSI used to create the latest patch that was failing. At this point I am leaning towards the theory that the patch is so large that it occasionally triggers a crash in the windows installer engine. – David Tarulli Jul 24 '14 at 23:23
  • This has nothing to do with the **msiexec.exe engine**. The action ISSetupFilesExtract is Installshield specific, and not a standard MSI action at all. – Stein Åsmul Jul 25 '14 at 17:25
  • As far as I can tell ISSetupFilesExtract just copies files from the binary table to a temp folder. In my project it's just 3 tiny files that never change. I don't see how the behavior of this action would vary depending on the size or complexity of the patch. This action isn't returning failure, execution just stops, which is why I suspected the windows installer engine. But I really don't know. – David Tarulli Jul 25 '14 at 18:53