Troubleshooting "error generating preview" in Installer

[10Degree]

From time to time, I have run into this maddening condition where I build an installer and it will not run because it reports “error generating preview” errors on the EXE for which I am trying to build the installer.  Most often, I can build the EXE just fine, without errors.  The run button does not show any problems, and the application EXE runs without issue.  When I try to build the installer, I get the error.  I have scoured NI’s web site and find many people with this problem, loads of “try this” type advice, and reports of “I fixed it” that often don’t make any sense.  It is nearly impossible to troubleshoot this problem in an orderly, sensible way.  Sure there are some build log files that can be activated, and you can look through them, but rarely is there anything “telling” in these rather verbose dumps (if they are created at all).  How is it that the Installer builder can notify me that there is an “error generating preview”, but cannot point me at the source of the error?!  How insane is that?

I would like to put out a passion plea to National Instruments Engineering, or to one of you many LabVIEW community gurus’s to provide some detailed instructions for diagnosing, finding, and fixing these vexing errors.  Can someone please write up some sort of step by step for this diagnosis?

The second thing I would love is for NI to report more detail in the Installer builder as to what is causing the error.  Telling me there is an error (that you just found) but keeping the issue a secret does not help me get my job done.

If there is already a detailed step-by-step guide for diagnosing and fixing these issues, I apologize for this post and would be very grateful if someone would kindly point me to this oracle of wisdom.

Thanks,

-cb

[Jeff-P]

Hi 10Degree,

Are you using LabVIEW 2013? If so there was a change to the way that installer builder works under the hood which has been causing these errors to crop up more often. This is being fixed in the LabVIEW 2013 f2 patch will be released later this month.

If you are running into the issue in LabVIEW 2013, a quick recommendation that will help you work around the issue is to go into your build specification for your exe (I am assuming you are installing an exe), go to the Additional Exclusions tab and uncheck the box for Remove unused members of project libraries. If you are running into the CAR being fixed in the f2 patch, this will cause your exe to fail to build. The underlying cause of the failure is the same as the reason your installer is failing, but the error will be more descriptive. It should throw error 7 file not found and direct you to a patch. The error generating preview is because unused VIs in a library you are using have unsatisfied dependencies. When we try and bundle those into the installer, we miss out on the dependency and throw the error. Installing the missing dependency will let you build your installer (or you can wait for the f2 patch). 

A general troubleshooting step for Application builder and installer builder - try generating a verbose log of the build by adding the INI token NI_AppBuilder_Logging=True to your LabVIEW.ini. This generates a detailed log for the build and will let you see how far into the build you are failing and should give you more clues to characterize the problem.

In general, we are always trying to improve our error messages to make them more useful where possible.

Thanks,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments 

[10Degree]

Jeff,

Thank you for your detailed reply.  This may be the first batch of truely useful information on this problem that I have found.  I definately have something to go on now to try and get my build issues straightened out.  If you want some user feedback on this aspect of LabVIEW from an "in the trenches" user, here it is plain and simple:

• Give the user the ability to look at a build log directly after trying to build - similar to how mass compile works.
• Include very clear clues in the build logs as to what went wrong and why it failed.
• Provide some additional auditing tools of some sort to help locate and remove these types of broken dependencies.

Thanks,

-cb

[10Degree]

Jeff,

I unchecked the "Remove unused..." box for the EXE.  This resulted in a much longer build time, but it eventually finished without error and successfully generated an EXE.  The installer still fails.  Here is the detail text from the failure:

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error -1 occurred at CDK_Utility_GenerateErrorCluster.vi -> IB_Source_Container.lvclass:Report_Preview_Error.vi

This error code is undefined. Undefined errors might occur for a number of reasons. For example, no one has provided a description for the code, or you might have wired a number that is not an error code to the error code input.

Additionally, undefined error codes might occur because the error relates to a third-party object, such as the operating system or ActiveX. For these third-party errors, you might be able to obtain a description of the error by searching the Web for the error code (-1) or for its hexadecimal representation (0xFFFFFFFF).

Any additional guidance would be appreciated.

-cb

[Jeff-P]

cb,

Based on your statement that the exe builds and the installer does not, I am confident you are running into CAR 429282 which is fixed in the 2013 f2 patch which was released earlier this week. The patch details are here and the download for the patch is here.

Please let me know if that fixes the issue.

Thanks,

Jeff Peacock

Product Support Engineer | LabVIEW R&D | National Instruments  

[Doug]

Hi 10Degree - I ran into the same thing in 2013.  I had software that built fine in 2012, but failed in 2013.  Patch didn't help.

Look in your project for missing vi's.  Apparently, 2013 doesn't like missing vi's even if they're in Diagram Disable structures.  I had one in my top level vi.  I deleted it and was able to build.

Good Luck,

Doug

[Sam_Sharp]

I have had builds fail before just because I had the build folder open in windows explorer. I guess that the OS was interfering with the build (e.g. trying to read file properties as they were being packaged up etc.).

Might be something to bear in mind if you had the build path folder open!

[z4gunn]

I too have found that upgrading to Labview 2013 breaks the installer build configuration on many of my projects.  Unfortunately the f2 patch did not solve my problem, however I did manage to find the culprit by enabling logging as described in this post.  The culprit in my case as a single missing typedef  (nirviPiFifoType_MemoryType.ctl) which seemed to be included in the FPGA toolkit.  I installed the trial version of FPGA toolkit and the problem was resolved.  

In my opinion this is not an acceptable solution since the Labview 2012 installer build configuration ignored this file without any issue.  Why can't the Labview 2013 installer build configuration automatically ignore unused types? 

[Jamey]

This is the same thing I am seeing. When I went to the NI website I found an FPGA Compile Farm Toolkit... is this what you are referring too? I also see an FPGA deploy Option in the 2013 installer files.. but they don't explicitly call it a toolkit. Can you give a little more direction to this fix, a link or installer name? I sure appreciate your post, I saw that earlier and just shrugged because it was so far down, I would have passed it off as some bug in the environment... or just a pointer to what the real problem was.

[10Degree]

Greetings Community,

Just circling back to report out on what I did to get my install build to work again.  This list contains things that *probably* fixed this issue on my system, although it is a bit of a mysterious issue so somewhat hard to nail down.  Anyway, these comments may help someone some day.

What might prevent the build of an installer

1. You have a VI in a Dialog Disable Structure that has a problem.  It could be a broken VI or a left-over VI that points to a VI that no longer exists.  Whatever the problem, just because it is "commented out" does not mean that the compiler will ignore it.  By the way National Instruments, I think this is a bug.  Why does the compiler try to process things that are commented out?
   
   
2. You have a String that is wired to the selector of a Case Structure.  I ran into this once.  I could not build the installer.  Somehow I found a reference online where someone commented on this being an issue.  I found my problem VI, replaced the string with a typedef into the selecter and poof, it worked again.
   
   
3. You have a hard-coded path reference in your VI that points to a directory that does not exist (invalid path).  In my case recently, I had a string with a path wired into a build path reference.  The directory was used elsewhere to open VI's on the fly.  For some reason this was OK with the EXE builder, but not OK with the installer builder.
   
   
4. Here is a "gotcha" - if you move a LabVIEW project to another directory, the installer forgets all of the file dependencies you have created in the installer setup.  When I get a new version of LV, I create a LV project directory called "LabVIEW 2013" and move my previous (and still active) projects into that directory.  I know this seems kind of dorky, but it helps me keep things straight.  When I move my projects, the installer break.  Trying to re-construct the build settings has been troublesome and can lead to odd "error generating preview" messages because something wasn't re-built correctly.

Well, that's what I know.  The F2 patch for 2013 did not fix my most recent problem, #3 above did.  If anyone finds other build issues to look for while troubleshooting, can you please post to this thread?

Thanks,

-cb