1334 Error - Tried Just About Everything I Can Think Of. Anyone know of some obscure causes....

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

Answers (6)

Posted by: rileyz 3 years ago
Red Belt

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?

  • 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! - Superfreak3 3 years ago
  • Uncompressed, loose files installs without issue. - Superfreak3 3 years ago
    • 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. - rileyz 3 years ago
  • 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. - Superfreak3 3 years ago
    • 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 - rileyz 3 years ago
      • 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. - Superfreak3 3 years ago
Posted by: EdT 3 years ago
Red Belt

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

  • 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. - Superfreak3 3 years ago
  • 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. - Superfreak3 3 years ago
  • 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. - Superfreak3 3 years ago
    • 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. - EdT 3 years ago
      • 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. - Superfreak3 3 years ago
  • 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. - Superfreak3 3 years ago
    • 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. - Superfreak3 3 years ago
      • 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. - EdT 3 years ago
  • 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!! - Superfreak3 3 years ago
    • 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...... - EdT 3 years ago
      • 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. - Superfreak3 3 years ago
      • Glad you got it solved! - rileyz 3 years ago
      • Thanks, me too! I think this one shaved time off my life!! - Superfreak3 3 years ago
    • Hello! I had the EXACT same problem as you, and it triggered after updating some NuGet packages used by my solution. I've looked at the build output from Setup Project in Visual Studio and found out the paths of the files being added to the cabinet. I've touched them and it worked for me too! Thank you very much! I hope anyone else with the same problem can find this page, because as you I've also searched a lot and tried several things without success, until I found this! I can't express enough how much I'm glad for that... - arfmach 3 years ago
Posted by: EdT 3 years ago
Red Belt

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.

  • 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. - Superfreak3 3 years ago
Posted by: andrewmoore01 1 year ago
White Belt

Quickbooks Error 1334 occurs when you try to update, install or repair the software program. It is the most frequent technical error you will see in Quickbooks. On the occurrence of the error, you will see the error message on the screen ‘’ERROR 1334. ‘Error 1334 Quickbooks’ appear on the screen and the active program window crashes, Windows run very slowly and respond very sluggishly to the keyboard or mouse input tab, Your device periodically freezes for a couple of seconds, Quickbooks is only loading but not working

Posted by: daniellisa 1 year ago
White Belt
If you are using Quickbooks desktop on a regular basis then you will like to know about the Quickbooks tool hub, it is your one-stop solution in resolving common errors. Other errors like install related errors, network-related errors, and much more. 
Posted by: steverex 1 year ago
White Belt

Intuit's Quickbooks Connection Diagnostic Tool is a tool designed, developed, and marketed to fix all types of errors related to Network connectivity and multi-user in Quickbooks Company files. Intuit offers this tool for free to QuickBooks users, so they can easily take advantage of it. The QB tool is specifically designed to deal with errors in the 6000 series and H series. Using this tool, the user can develop a connection to other applications such as Quickbooks database manager and Quickbooks Company records.

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ