Build error 13 using LVAddons

[eberaud]

Hi everyone,

I recently installed LabVIEW 2023Q1 and am trying to compile (create an executable of) my company's application, that we can successfully compile with LabVIEW 2019. Unfortunately, at the end of the compilation I get an "error 13" message, just like in this link:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000g34oSAA&l=en-CA

However, I don't think it applies to me, since this was supposed to be only in LabVIEW 2017, and that my "Use fast file format" is already disabled anyway.

When trying to remove/add back part of my source code, I notice I tend to have problems when I include code that have dependencies inside the new LVAddons folder (C:\Program Files\NI\LVAddons) that NI came up with in LabVIEW 2022Q3 (specifically, xnet and daqmx).

Googling specifically for building errors with LVAddons, I came across this issue reported by JKI:

https://github.com/vipm-io/vipm-desktop-issues/issues/17

Since it's related to building a package and not an executable, I'm not sure it's relevant for my situation.

What makes it hard to troubleshoot is that everything looks happy in the lvproj. All dependencies are found in LVAddons instead of C:\Program Files (x86)\National Instruments\LabVIEW 2023\vi.lib, which seems to match NI's intentions. And the error only occurs at the very end of the compilation.

Has anyone encountered this problem while building with either LV2022Q3 or LV2023Q1?

I have installed the latest versions of NI-XNET and NI-DAQx drivers (2023Q2).

The whole error message is as follows:

Error 13 occurred at Invoke Node in AB_Engine_Write_Linker_Wrapper.vi->AB_Build.lvclass:Copy_Files_Core_Old.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_EXE.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
Shareable board exclusively owned.

Method Name: Linker:Write Info To File

[Darren]

I think this issue may have been fixed in LabVIEW 2023 Q3. Are you able to upgrade and try it out?

[eberaud]

Thank you Darren,

I upgraded to 2023 Q3 and it did fix the issue. I had managed to strip down my code to the point where all I had was one empty class with just a .NET refnum in its private data (System.Windows.Forms.NotyIcon), and only a "DAQmx Start Task.vi" in the startup VI. Same thing was happening if instead of the daqmx VI, my startup VI contained a "XNET Create Session.vi". Any chance you could explain what the issue was? If I removed the .NET refnum or the DAQmx (or XNET) subvi, then it would compile fine.

I am attaching a zip file with the files I mentioned and the .lvproj itself (in LV2023Q1) in case somebody want to test it on their own PC (you would need to install DAQmx and/or XNET drivers of course).

Anyway, now that this is fixed, I resumed building my whole project and I'm now running into an error 2 "memory is full" 🤯.

Cheers,

error 13 investigation.zip

[Darren]

The issue was reported to LV R&D as Bug 2317159. It was introduced in LabVIEW 2022 Q3 and fixed in LabVIEW 2023 Q3. The Error 13 occurs when the LabVIEW Class private data includes certain types of .NET references, or a reference to a .chm help file.

More details: LabVIEW 2022 Q3 included a "fix" to how linkages to .NET assemblies are adjusted in a build output. Unfortunately this "fix" caused the issue you're seeing. LabVIEW 2023 Q3 uses a new mechanism for app builder caching under the hood, which removed the codepath that was causing the Error 13 altogether.

[eberaud]

Crystal clear. Thank you Darren!