Error 13 when compiling exe with LV2023Q1

[Manudelavega]

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.

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

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

[Manudelavega · Accepted solution]

Some news about this topic: Darren N. told me to upgrade to LabVIEW 2023 Q3 and voilà it's fixed! I don't know the details and I would love it if someone knows what's going on and could explain it here. For more details, I'm pasting my reply from the Lavag:

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". 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" 🤯.

[_carl]

I encountered this same issue in 2023 Q1, but migrating to 2023 Q3 did not fix my issue: building in Q3 would just freeze.

After lots of wasted time, I did find a solution though!  Here's what worked:

- Backsave the project to LabVIEW 2022.

- Open up the code in 22 ... and voila...  it had broken VIs.

- These VIs were broken because LabVIEW 2022 determined they needed to be reentrant.  Note that LabVIEW 2023 did not detect this reentrancy need, nor were there any issues in running the dev code in LabVIEW 2023.

- After changing the original 2023 VIs to be re-entrant, I was able to successfully build in LabVIEW 2023 Q1.

(And yes...there were VIMs involved in the reentrancy loop.)

[IlluminatedG]

We just started running into this, with no .Net in use. Based on the info in these forums and the KB we thought it might have been XNET but removing that did not help.

The project was setup such that a folder containing a library was set as always included and the option to strip unused library members was disabled so the library wouldn't get blown away by AppBuilder if all of it didn't get statically referenced.

I moved the module out of that always included folder above the folder in the project and then it built. Best I can tell is it just changed the order of what got handled during the build and that let it pass through. We have built this app before without issue so this one is really a head scratcher; this was on a LinuxRT target.