Deployment Utility Errors

[CJames]

Hi,

We're having a problem with building an installer using the TestStand Deployment Utility. We added some sequence files, VIs and image files to an existing installer and now it doesn't work.

Below is an extract from the log file:

Internal error code -2147023170 Processing VIs...
Could not process LabVIEW VIs. Fix any broken VIs before rebuilding. LabVIEW error:
The remote procedure call failed.
 in Dynamically Call Build VI Distribution LV 8.6 or Above - TestStand.vi->TestStand - Call Build VI Distribution for Unique VI Hierarchies LV 8.6 or Above.vi->TestStand - Package VIs.vi->TestStand - Build.vi->TestStand - Distribution Wizard GUI.vi->TestStand - Deployment Utility Splash Screen.vi
An installer was not created due to an error
The build process is done.
9:19 AM
Aborted

If we split it into 2 installers, with the majority of the LabVIEW VIs in one and the rest of the code in the other both installers build properly and when installed on another PC everything seems to work as expected.

We have mass compiled all of the VIs, and opened and re-saved all of the new ones. We also tried adding more memory to the PC as we wondered if the installer was just too big (there are over 2000 custom VIs) but that didn't help.

We are using LabVIEW 2009 and TestStand 4.2.1.

Any suggestions would be greatly appreciated!

[Perry_S]

Hi CJames,

Have mass compiled all subVIS that are being called as well? Here are some references that I found concerning this error;

Error -2147023170

Activex Calls Generate Error -2147023170 With Microsoft Excel

It seems that it is an execution timing issue. Let me know if this gives you a clue.

Regards,

Perry S.

[V_T_S]

Hi CJames,

Make sure you have no borken code or missing modules in the disabled diagram.

[CJames]

Hi everyone,

We have done the Mass Compile on all of the VIs, and it doesn't report any problems so I don't think there's anything broken or missing.

At the moment we have found an interim solution where we can have just one installer and it works - we tell the TestStand Deployment Tool to exclude vi.lib and we include it separately as a zip file and put in a custom command to unzip and install this folder as part of the install process. This seems to work but the downside is that we have the whole of vi.lib included in the installer so hopefully we can find a better solution.

Also maybe this can direct you to a better understanding of what the problem might be?

Thanks for your suggestions.

[Perry_S]

Hi CJames,

Did you Mass compile the vi.lib folder as well? Also do you run out of memory when trying to build the installer with the vi.lib folder included? When trying to build the installer with the vi.lib folder included which process takes up the most resources? Take a look at your task manager and let me know.

Regards,

Perry S.

[flaborde]

CJames,

The error message you are getting means that the connection from the Deployment Utility to LabVIEW was broken unexpectedly, probably because LabVIEW had some problem it could not recover from. From your investigation it seems like the problem is that your deployment is so big that LabVIEW is running out of memory while deploying. There are several ways you can fix or mitigate this problem.

The easiest way would be to set the /3gb switch which makes LabVIEW run in large address-aware mode. For more information please read this KB. This will allow LabVIEW to use more virtual memory and it should allow the build to complete, however, this is only a temporary solution because if your project continues growing there will come a point where even this new amount of memory will not be sufficient. 

Another thing you can do from the architectural point of view is splitting your VIs into different projects (and calling the VIs in the context of a project from within TestStand). The Deployment Utility will create a different deployment for every project, which means that some of your VIs which are currently being loaded together while deploying would not be loaded together anymore. This, however, is more complicated because you have to make sure that the VIs are not part of the project anymore (that is, they are not dependencies which would include them anyway) and you have to make sure that they are divided in logical groups. 

Hope this helps,

- Francisco