Unhandled MSI error message on run of built Setup.exe

[Mark_Ramsdale]

I rebuilt my project and error fixed.

The project I was using was several months old.  I updated all my MSI configuration on targets and development boxes and still had the error.  I made a new project for the app and then the installer worked correctly.

FWIW I tried rebuilding my installer in the original project, that did not work either.

Effective solution in my case.  Wonder why that fixed the error, not sure the technical answer would help 🙂

[bef]

I had the same problem and I think I know what might be wrong...

In my case I didn't use the default directory as destination. I added a new "sub-directory".

So instead of using "program files\myapp" I generated "program files\myName\myApp".

This works well if you start the build-process right after setting it up.

But it seem LV2010Sp1 does not save this configuration correctly.

So when I save the project and open it again, all the source files are gone.

If you just start the build-process now, a new installer is created, but running it on a target gives the MSI-error.

Workaround: Use the default destination (program files\myApp). 

NI, could you fix that soon?

Thanks! 

[bef]

Maybe I was a little triggerhappy with my post above.

At the moment I can't reproduce the error.

I'm sure that for some reason the definition of the source files can get lost. And building an Installer with no source files defined gives that MSI error.

But I'm not sure under which conditions these settings get lost.

Sorry for being a little unprecise here 🙂 

[Andromeda]

I am encountering this problem as well, using LabVIEW 2011.

The installer works correctly on my development machines (Windows 7x64), but consistently fails for clients running Windows XP.

However, it appears that this is not an OS-specific issue, but an NI bug which has gone uncorrected for several years.

If anyone has encountered this issue, I would appreciate hearing how you worked around this bug.

[Chris-G]

Hi Andromeda,

The simplest question to ask is: are the deployment machines 32 bit computers? and are you developing the installer using a 64 bit development environment? If so, this is probably causing the error. If this is the case, you'll have to build your installers in a 32 bit environment if you want to run them on 32 bit computers.

If this isn't the case, have you tried simply creating a new project and then rebuilding the installer from this new project as suggested previously in this post? Do you have the latest MSI updates on the computers?

Chris G

[drummaniac83]

I experience this problem all the time.  Running windows 7 64bit with Labview 2010 SP1 32 bit.  It cropped up after the SP1 update.

Ways of making it happen:

Create Installer and set it up.

Build Installer

Now go to properties and delete folders in destination, create new destinations and try to assign one of these new folders as the default folder.

You now may have issues just adding files to these new folders under "source files"

If you are able to add files and build the installer, you will get this installer error 100% of the time.  Regardless of if you delete the entire volume folder or not.

The only workaround I have found is creating a brand new installer and starting over.  Even duplicating a corrupt installer inside the project causes the same problems.

I am downloading the f4 patch right now to see if this fixes it.

Thanks,

Josh

Certified LabVIEW Architect

[Andromeda]

Thanks for your reply Chris,

I did rebuild this installer using a 32-bit development environment, and still encountered the same issue. Unfortunately "simply creating a new project" is a multi-hour process, due to the size of the project.

However, preliminary testing on a version of the installer which does not attempt to install most of the destination directories appears to be successful, so Josh (next message in thread) appears to be correct in thinking that this is a project file corruption issue. I have also encountered project corruption issue so very many times that I can't even count them - particularly when modifying source and destination trees.

Regards,

John

[drummaniac83]

I'm very convinced now that it is related to a bug or conflict between labview and windows and the destination directory.

I tried the 2010 SP1 f4 patch.....didn't help

then opened the project in 2011....also didn't help...

I created a completely new project in 2011 and copied over all the files.  Made an entirely new executable and installer.  I could still cause the problem at will.  Just by deleting and creating new destination directories in the installer properties

so I tried an experiment.  I rebuilt a new project, but instead of deleting the default destination directory tree, I just added my own folders in the locations I want, and then changed the default folder.

This seemed to work perfectly.  It may still become corrupt if I ever try changing the destination folders, but that seemed to work.

Again this isn't something that can be "updated" with the MSI version....newest version is from 2008 which is older than what windows 7 has built in.

NI, I would be more than happy to provide you with more details on this issue if you are actually interested in looking at it and not just requesting me to upgrade to the latest version of MSI or "just create a new project" b/c those aren't solutions.

[drummaniac83]

I'm very convinced now that it is related to a bug or conflict between labview and windows and the destination directory.

I tried the 2010 SP1 f4 patch.....didn't help

then opened the project in 2011....also didn't help...

I created a completely new project in 2011 and copied over all the files.  Made an entirely new executable and installer.  I could still cause the problem at will.  Just by deleting and creating new destination directories in the installer properties

so I tried an experiment.  I rebuilt a new project, but instead of deleting the default destination directory tree, I just added my own folders in the locations I want, and then changed the default folder.

This seemed to work perfectly.  It may still become corrupt if I ever try changing the destination folders, but that seemed to work.

Again this isn't something that can be "updated" with the MSI version....newest version is from 2008 which is older than what windows 7 has built in.

NI, I would be more than happy to provide you with more details on this issue if you are actually interested in looking at it and not just requesting me to upgrade to the latest version of MSI or "just create a new project" b/c those aren't solutions.

[Andromeda]

Thanks for your comment Josh,

I also have encountered project file corruption on so many occasions that it is usually my first go-to when problems arise. I'd been reluctant to do it this time, just because the project is large enough that it takes a fair while to create a new project - but sure enough, a fresh project seems to be able to create a working installer. So far, I haven't asked the installer to create most of the target directories.

Like you, I've seen project files get corrupted when making changes to the destination directories, and I think that the 2010 SP1 release might have been when I started running into it.

I had made quite a lot of changes to this project, because of another bug in the application builder (dynamically loaded VIs, even when included in the "always included" source file list, do not get their dependent VIs from vi.lib included in the built application), so there might have been other changes that caused the always fragile project file to become corrupted.

Now that I have what seems to be a project project file, I can save it as a starting point for creating the full installer which does attempt to create more destination directories.

It's too bad that the project files are so darn fragile. The thing about XML is that it is a file format that can easily be checked for corruption. Since there are start and end tags, a tree parser could check XML trees both forwards and backwards, were NI to develop a utility for repairing corrupt project files.

It's also too bad that the problem of project files being easily corrupted has been around for so long. As a general principle, I'd suggest that the project file editor should only be permitted to emit syntactically correct XML project files.

Again, thanks for your help – that was indeed the problem.