/build/static/layout/Breadcrumb_cap_w.png
03/01/2019 291 views

Hi all,

All of a sudden our web app installation is erroring with a 1334 - file cannot be found in .cab file.  We are currently using InstallShield 2018 SP1.  I've tried everything I can think of or found online, but I just can't get past this error.

I've removed the problematic component to see if it was some type of file problem, but the error just moved on to another file in the installation.  Removed that, error just moved on to different file.

I even compiled a previous, released version which hasn't been touched in weeks and it errored on the same exact file.  The source files for that release are in a completely different location, of course, than the originally failing release.  My thought was maybe the source files were on a bad area of disk or something like that.  That led me to believe that it might be something with InstallShield itself that went awry, .dll, a configuration setting or something like that.  I repaired our InstallShield instance, no luck.

Ran chkdsk, no luck.

I've tried different compression settings in the Release settings, no luck.

I tried adding a different Release configuration, no luck.

I tried moving the .ism project directory, no luck.

I sent the build log and .ism to InstallShield support and they didn't see anything out of the ordinary there.  They said they've seen this error with weird or missing file dates, but that is no the case here.

Does anyone know what else I could try?  Any obscure cures?

Info MUCH Appreciated!!

0 Comments   [ + ] Show comments

Comments


All Answers

0

Well that's a bit of problem, isn't it.

Have you tried to looking at the problem post build? Install the MSI with logging enabled, then cross reference the files via the Tables in the MSI. 


About your compile, how is your media streamed? ie, streamed CAB into MSI, external CAB or loose files? Have you tried the variations mentioned?

Answered 03/02/2019 by: rileyz
Red Belt

  • Ha! I didn't even think of trying uncompressed. Doing that now. I believe through InstallShield, that would be the loose file method you mentioned. I'm not sure how to create the .msi with an external cab file via InstallShield.

    Can you expand upon what you meant by logging and cross referencing the files via the table in the .msi. Do I see a file that errors in the log. What should I be looking for in the tables.

    I believe I have extracted the .cab file and the file was in fact in the .cab, but I will double back on that.

    So, right now I know the streamed CAB into .msi is not functioning properly. Will update with loose files.

    And THANKS so much for the response!
  • Uncompressed, loose files installs without issue.
    • Humm wonder whats happening with the files during the build into the CAB. Have you tried a external CAB? You have to choose Media Type: Custom when doing the build, then compress all file - might need to play around with the settings.

      Regards to testing, after the compile, check with InstEd or Orca to check that the Files in the FILE Table corresponds to the correct CAB file in the MEDIA Table. In the FILE table you will see the Sequence attribute which you can cross reference with the LastSequence attribute.

      Interesting problem you have though.
  • I double checked the problematic package and the files in question are contained in the cabinet file.

    I'll now log it and hopefully something other than the error. Not really sure what I'm looking for outside of the error itself.
    • Quick one, thought I'd better ask just in case, you do preform Package Validation? Ie, run the checks for ICE errors.

      Build > Validate > Full MSI Validation
      • I did and there are errors in there. I normally don't run the validation checks and haven't for years. I've turned validation off, but will turn on and run again.
0

SF3 -

What schema is the MSI using?

How many files are in the package and how many components in the feature? You should recall from your time in the Wise forums that there were schema limits in the early schemas for the number of components in a feature, etc.  If this is a small package with only a few hundred files at most then it's unlikely that these limits are being exceeded, but worth checking just in case, as this might account for the error in the cab reading. What is the sequence number of the file that the install is failing on?  If it is 800 then its a limit thing if I recall correctly.

When validating, see if there are any reported issues with table entries exceeding the table schema - it is not uncommon to find filenames in the file table that are longer than the space allocated for the name column in the file table. Generally this has no discernible effect, but who knows what truncation may be going on inside Installshield which leads to the cabs being incorrect.  Clearly if the MSI works with external uncompressed files then it has to be an issue with the compression of the files into the CAB.  Check if there is an option to have one CAB per file and see if that works.

Hope this gives you a few ideas to help in diagnosis

Answered 03/02/2019 by: EdT
Red Belt

  • Thanks EdT, I'll check these things out. InstallShield examined my .msi and verbose log and they indicated all looked OK. I'm not sure if that means that some of the stuff you mentioned was covered in their analysis or not.

    This isn't a small package. Its a Web app and has tons of files.

    I don't know if I'm reaching/exceeding limits. One day everything was fine, the next day, 1334 errors. There were not new file additions in between.

    Where do I find the sequence number of the problematic file? Are you talking about the sequence column of the file table. All files are sequenced 1 in all of my install templates.
  • As far as validation goes, here are the suites I'm running...
    InstallShield Validation Suite for Windows 8
    Full MSI Validation Suite
    InstallShield Best Practices Suite

    The most common error found during validation is Component <component name> does not have the Option Header bit safeSEH set.

    I don't see anything else that may be related.
  • Another thing I find strange is that our previous release was fine. It ran through QA for months and was shipped. The next compile, first since release with no source file changes, just a compile to see if the installation had the same issue, was problematic.
    • Was this original package created by capture or by some other means? Where are you getting the source files for recompile? Are you making sure to delete any existing MSI files in your project folder before recompiling? I don't know if Installshield does the same as Wise did, which is to "edit" an existing MSI when recompiling rather than recompiling from scratch - this option was on by default in Wise and always needed to be turned off as it would screw up more MSIs than you can shake a stick at, and the time saving was not that big. One other thing you can do is to run MSIDiff on the original working MSI against the faulty recompile and see where the differences are within the tables.
      • The original package was build from scratch, no capture. The source files from recompile are grabbed from a CI staging area and copied to the install build server. I believe InstallShield deletes pre-existing .msi at compile time. I'll look for an option for that, but I can't really monitor it in real time because the build errors if the directory is being accessed. That most likely indicates that the .msi from a previous build is whacked.

        Good thought about MSIDiff. I'll give that a shot.

        Right now I'm going to test the cab/file build.
  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.
  • So, I got around to testing the cab/component compression method and here is what happened. I copied the DISK1 build output folder to my test machine's desktop and executed the setup.exe. I then received a 1311 error - Source file not found in \Local\Downloaded Installations\{GUID}\DND_Ad~1.cab. I guess there was some problem copying the files so I manually copied the files from DISK1 output folder to the location mentioned in the error and Retried. This time, the files installed without issue. So, I don't know if the 1311 error was just a fluke or hints another problem. It seems that cab/component compression was successful or not problematic. I don't really know where I'm at or what this shows at this point.

    My next step is to run MSIDiff.
    • The 1311 error was caused by the cache locally setting. With that set to yes, the .msi is cached, but the external cabs are not, I guess.

      Here is where I am at at this point.

      Uncompressed - Works!
      Compressed Cab/Component - Works!
      Full Compression - 1334 Error

      Working on MSIDiff now.
      • Just a thought, but is there an antivirus on your system? It could be flagging a false positive on the compressed can and preventing extraction.
  • I found the problem. I was examining the files indicated in the error, but the problem was the file directly before that file in sequence. It did not have a modified date. Touching the file to modify that date and recompiling did the trick.

    My mind was spinning during this so if someone mentioned that I'm sorry for my oversight.

    I'm just glad its fixed!!! Thanks for all the input!!
    • Now it just remains to figure out why it worked previously - or was the file in the original compilation correct in having a modified date? It's good to know the actual cause of the error, but I have a feeling that the issue is either indicative of a tightening up of MSI rules in the operating system, or an indicator that the place where you store the source files has an integrity problem. So perhaps the problem is not entirely solved just yet......
      • Its really hard to say. This file belongs with a piece of the software that is not part of CI, but deployed by a developer(s) to a staging area for install builds. They may have just deployed that 'stuff' again early on in the day when the error showed itself.
      • Glad you got it solved!
      • Thanks, me too! I think this one shaved time off my life!!
0

In my experience unless you give the developer group a good whacking with a wet kipper once in a while, they will continue to waste your life with dodgy releases.

At the very least they should take you out to lunch and fill you with beer/wine/spirits to reward you for your efforts.

Answered 03/06/2019 by: EdT
Red Belt

  • Trying to keep that group in line is like trying to herd cats!

    It looks like a fluke of some sort. The developers deployment of the involved file was earlier in February so the file was good as the previous release I spoke of, which was shipped, occurred after that date. We've had some rough weather with power outages and I'm wondering if it was a hiccup during a backup operation of our staging server or something crazy like that.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share