cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
NeilHayes
Level 5

Patching limit

I have an RTM install of 26537 files.
I build an updated install with just updated files where 11,808 files have been modified of the 26537.
No other changes whatsoever.

InstallShield is unable to build a patch with error error -6415: There was an error creating the patch package.

Log file gives this:

ERROR: Failed to execute view: 'File'
ERROR: The Last Error Received is: 0x65b (1627)
ERROR: The Last Error Received is: 1: 2210 2: \\?\C:\Users\NEIL~1.NTD\AppData\Local\Temp\~pcw_tmp.tmp\Prev1.MSI 3: 0

I searched the forums and tried various solutions to no avail.


So I resorted to WiX to build the patch and I could actually build the patch but it fails to deploy basically saying it can't find a given file in the cabinet during the copy file process.

So I begin to wonder if my problem is more around the volume of files and the ImageFamilies Table used by PatchWiz.dll.

Trying to understand the meaning of the columns in this table I come across "FileSequenceStart" which is an integer.

From MSDN it states the following:

This field is the sequence number for the starting file. This same file sequence number must not exist in two patches for the same product. To ensure this, the value in this field must be greater than all sequence numbers used in previous patches or in the original installation package. The greatest sequence number in a patch can be determined by adding the total number of entries in the patch cabinet file to the FileSequenceStart number for that patch. One way to determine this is to look at the .ddf file generated by Patchwiz.dll during the creation of the patch. The limit for FileSequenceStart is 32767. This field can be null only if you are using version 2.0 of Patchwiz.dll and if the MinimumRequiredMsiVersion in the Properties table (Patchwiz.dll) is set to 200.

So now it must come down to my interpretation of the value of the field. If my original install has sequence numbers ranging from 1 to 26537, my next sequence of numbers should start at 26538 for 11,808 but this would exceed the limit of the FileSeqeneceStart value of 32767.

Therefore is it that this application cannot be patched?.

Is my interpretation correct?

Neil
Labels (1)
0 Kudos
(6) Replies
NeilHayes
Level 5

Well after many days searching looking at cryptic error messages, reading tonnes of stuff and trying recommendations, I now think I understand what the problem is and solution.

First....there is no solution to an already deployed MSI.

The problem is due to the original shipping msi database and schema with which it was created, and in InstallSheild terms the file "ISMsiPkg.itp" which sits in "C:\Program Files (x86)\InstallShield\2014\Support\0409".

I manage more than 60 installation programs, of which 59 of them are relatively small with probably no more than a couple of 1000 files. When I build install no 60 I did it in exactly the same way as the other 59, not knowing that in the future I might hit the MSI schema and table limit.

The default file (ISMsiPkg.itp) that Installshield uses to build the MSI databases is limited to 32676 (i2 or a short integer). Three main tables are involved in my case, Files, Media and Patch and on top of that _Validation.
When you build a patch the "Sequence" number in the files table will be increased, in my case I exceeded 32676 hence the patch fell over during the build using InstallShield.

What needs to happen for the next "Product" release of project 60 is the replacement of ISMsiPkg.itp with IsMsiPkgLarge.itp where the limits are higher. So basically I will rename ISMsiPkg.itp to be ISMsiPkg.itp.orig and rename IsMsiPkgLarge.itp to be IsMsiPkg.itp.

The action of this renaming of course is a global change and will effect all future projects.

It's also important to note that I cannot update the old Project 60 with a newer build, built using the large schema as the two msi databases would have a mismatch.

One has to ask why don't InstallShield make IsMsiPkgLarge.itp the default schema it would make so much more sense and I wouldn't have burnt my fingers big time!

The consequences now of implementing this to automation build servers just became complicated.

Perhaps this will save someone in the future.

Neil
0 Kudos
JSClark
Level 6

This is great information Neil.

Thanks for sharing.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

This is a tough problem to fully crack. While changing the schema of the .msi is reasonably well supported, it is documented to be a (short) integer. While it's an easy call to change the schema if a package is too large to fit within those limits, it's unclear when to do so preemptively, as any metric could turn it on when a preceding package used the smaller schema.

My general recommendation here is to steer towards separating out the contents of your package into multiple .msi files and distribute these with a Suite project (if you have the Premier edition). This will enable you to create smaller more targeted packages and patches, install them all within a single UI experience, and hopefully means you never have to worry about the 32k file limit. But that's clearly a scenario you have to design up front; getting there from here will likely involve at least one major upgrade. Whereas in your scenario you can probably still build and deliver a minor upgrade, just not a patch.
0 Kudos
gwesterfield
Level 3

MichaelU wrote:
This is a tough problem to fully crack. While changing the schema of the .msi is reasonably well supported, it is documented to be a (short) integer. While it's an easy call to change the schema if a package is too large to fit within those limits, it's unclear when to do so preemptively, as any metric could turn it on when a preceding package used the smaller schema.

My general recommendation here is to steer towards separating out the contents of your package into multiple .msi files and distribute these with a Suite project (if you have the Premier edition). This will enable you to create smaller more targeted packages and patches, install them all within a single UI experience, and hopefully means you never have to worry about the 32k file limit. But that's clearly a scenario you have to design up front; getting there from here will likely involve at least one major upgrade. Whereas in your scenario you can probably still build and deliver a minor upgrade, just not a patch.



I am experiencing the same exact error, even when I don't add any new files. If all I do is change the version between the msi's I get the error. Also, the patch log has a ton of "INFO File Key: _(GUID) is newly added" logs which is what I think is accounting for the patch hitting the limit as you can see below. What I don't understand is all the files are 100% identitical and the only changes I have made to the ism is the version. Any idea what could be causing these new file keys to be added when there are no new files?

INFO File Key: _54EA9BFC14E7710A5F19837CADA1E8CA is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _DC3ECD300D578635A09A69FFE4D8B3DC is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _E77E3757AA11E347958F54916D847290 is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _2DED20C450A5C40DAE0B11D9DB43B19F is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _2A5B77D2B5631605ABEEE34C34B6F7E1 is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _1FD7C352264C433D907DEE909493A7B9 is newly added
PERF INFO: File Info Lookup Time: 0 ms
PERF INFO: V:\t\911\Prev1\AirWatch.msi 47216 ms
PERF INFO: V:\t\Console FP1\9.1.1.3\Latest1\AirWatch.msi 47299 ms
SCHEMA: Table: Patch has mismatched schema (or missing column) for: Header
ERROR: Failed to execute view: 'File'
ERROR: The Last Error Received is: 0x65b (1627)
ERROR: The Last Error Received is: 1: 2210 2: \\?\C:\Users\GWESTE~1.VMW\AppData\Local\Temp\3\ISPE6B8.tmp\Prev1.MSI 3: 0
0 Kudos
Cary_R
Level 11

gwesterfield wrote:
I am experiencing the same exact error, even when I don't add any new files. If all I do is change the version between the msi's I get the error. Also, the patch log has a ton of "INFO File Key: _(GUID) is newly added" logs which is what I think is accounting for the patch hitting the limit as you can see below. What I don't understand is all the files are 100% identitical and the only changes I have made to the ism is the version. Any idea what could be causing these new file keys to be added when there are no new files?

INFO File Key: _54EA9BFC14E7710A5F19837CADA1E8CA is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _DC3ECD300D578635A09A69FFE4D8B3DC is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _E77E3757AA11E347958F54916D847290 is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _2DED20C450A5C40DAE0B11D9DB43B19F is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _2A5B77D2B5631605ABEEE34C34B6F7E1 is newly added
PERF INFO: File Info Lookup Time: 0 ms
INFO File Key: _1FD7C352264C433D907DEE909493A7B9 is newly added
PERF INFO: File Info Lookup Time: 0 ms
PERF INFO: V:\t\911\Prev1\AirWatch.msi 47216 ms
PERF INFO: V:\t\Console FP1\9.1.1.3\Latest1\AirWatch.msi 47299 ms
SCHEMA: Table: Patch has mismatched schema (or missing column) for: Header
ERROR: Failed to execute view: 'File'
ERROR: The Last Error Received is: 0x65b (1627)
ERROR: The Last Error Received is: 1: 2210 2: \\?\C:\Users\GWESTE~1.VMW\AppData\Local\Temp\3\ISPE6B8.tmp\Prev1.MSI 3: 0


This sounds like you may want to look into 2 things:

1. "Best Practice" dynamic file links. (The default when created newly in any recent IS version--not the default if you're maintaining a project created a long time ago)
2. The "Previous Package" setting in the release configuration. This tries to synchronize primary keys to avoid errors like you're mentioning.

What's likely at play is that the legacy style dynamic file links are generating new primary keys every time you build. This isn't likely your only issue if you're generating patches:


  • files left behind on uninstall
  • when folders are removed, no files updated by the patch
  • patch file size is weirdly large
0 Kudos
gwesterfield
Level 3

Cary R wrote:
This sounds like you may want to look into 2 things:

1. "Best Practice" dynamic file links. (The default when created newly in any recent IS version--not the default if you're maintaining a project created a long time ago)
2. The "Previous Package" setting in the release configuration. This tries to synchronize primary keys to avoid errors like you're mentioning.

What's likely at play is that the legacy style dynamic file links are generating new primary keys every time you build. This isn't likely your only issue if you're generating patches:


  • files left behind on uninstall
  • when folders are removed, no files updated by the patch
  • patch file size is weirdly large


Setting the "Previous Package" fixed the issue. I also went ahead and set all of my dynamically linked directories to the new "Best Practice" setting. Thanks for the help!!
0 Kudos