Frustrating Build Issue

[Mark_Yedinak]

I am experiencing a very frustrating build issue with LV 2018. My application build keeps crashing and the log file contains the following after every crash:

<Bunch of generic stuff>

starting LabVIEW Execution System 14 Thread 0 , capacity: 24 at [3816363687.88565207, (15:01:27.885652066 2024:12:06)]
starting LabVIEW Execution System 14 Thread 1 , capacity: 24 at [3816363687.88565207, (15:01:27.885652066 2024:12:06)]
starting LabVIEW Execution System 14 Thread 2 , capacity: 24 at [3816363687.88565207, (15:01:27.885652066 2024:12:06)]
starting LabVIEW Execution System 14 Thread 3 , capacity: 24 at [3816363687.88565207, (15:01:27.885652066 2024:12:06)]
LINKOBJ_BROKEN: LinkObj w/ identity [LinkIdentity "Message Logging.lvlib:Formatted.lvclass" [ My Computer Build Context]
UDClassLibrary::SetSelfErrorsCORE - missing parent on [LinkIdentity "Message Logging.lvlib:Formatted.lvclass" [ My Computer Build Context]
parent is [LinkIdentity "Message Logging.lvlib:File System.lvclass" [ My Computer Build Context], flags are 16
mFlags=16930
VI_NOTBROKEN (3): [VI "Message Handler.lvlib:Message Handler.lvclass:Message Process Server.vi" (0x1dc43740)]
SetVIIdle on a previously viBad VI: vi=true
VI_NOTBROKEN (3): [VI "Message Handler.lvlib:Message Handler.lvclass:Start Process Server.vi" (0x1dc4ea00)]
SetVIIdle on a previously viBad VI: vi=true
VI_NOTBROKEN (3): [VI "Message Handler.lvlib:Message Handler.lvclass:Message Server.vi" (0x1dc4f450)]

<A whole bunch of similar error messages for different libraries/vis>

I have opened every single VI of every library/class listed in the log. None are broken VIs. The project containing the application that I am building shows no errors and the VI that is being built for the application runs fine in the development environment. I have cleared the compiled cache numerous times yet every build will still fail. This is quite frustrating. The builds had worked several times and then after very minor code changes the builds starting crashing every build. All code is marked as separate compiled code from source.

Any thoughts on how to resolve this issue?

[paul_a_cardinale]

1. Revert to the version before the "very minor code changes" then rebuild to confirm that LabVIEW has not been damaged.
2. Reimplement those code changes one at a time, rebuilding each time.
3. Take a close look at the change that results in the build crashing.

Other points:

• Don't have an uninitialized shift register that holds a class.
• If possible clear all class mutation histories.
• Watch out for certain combinations:
  • XNodes inside malleable VIs.
  • XNodes inside Express VIs.
  • Malleable VIs inside Express VIs.

[Mark_Yedinak]

Thanks for the suggestions.

Finally able to get back to looking at this issue again. I looked through what SCC was saying was modified and I found 3 VIs that were marked as changed that I did not update. It should be noted that all of the code is marked to separate compiled from source. I reverted those back and the build is working again. I can't wait to get off of LV 2018 but for the moment I am restricted to it due to some older machines running old Windows Server 2012. There is a plan to migrate to newer servers but that has not been completed yet.

In terms of your three bullet points, points 1 and 3 are a non-issue as they don't exist in the code. I haven't really checked about clearing the class mutation histories but will keep that in mind for the future.

[Mark_Yedinak]

So here I am once again struggling to get this application to build. Somehow at the end of December I was able to get a build that was successful. No clue why it worked but I was glad it did. Well now I have some additional updates that I need to get built and I am running into the same issues. The application build without issue on a Windows 10 machine but will not build on a Windows 2012 Server. Yes, I know it is outdated but I have to live with it for a bit longer. The application built on Windows 10 will not run on the 2012 server as it reports an error loading a Windows dll which is not present on the 2012 server. So, I need to build on the server.

Again, I am seeing the same errors:

starting LabVIEW Execution System 14 Thread 1 , capacity: 128 at

[3822533146.01766396, (00:45:46.017663956 2025:02:16)]
starting LabVIEW Execution System 14 Thread 2 , capacity: 128 at [3822533146.01766396, (00:45:46.017663956 2025:02:16)]
starting LabVIEW Execution System 14 Thread 3 , capacity: 128 at [3822533146.01766396, (00:45:46.017663956 2025:02:16)]
LINKOBJ_BROKEN: LinkObj w/ identity [LinkIdentity "Message Logging.lvlib:Formatted.lvclass" [ My Computer Build Context]
UDClassLibrary::SetSelfErrorsCORE - missing parent on [LinkIdentity "Message Logging.lvlib:Formatted.lvclass" [ My Computer Build Context]
parent is [LinkIdentity "Message Logging.lvlib:File System.lvclass" [ My Computer Build Context], flags are 16
mFlags=16930
VI_NOTBROKEN (3): [VI "Asset Management Service.lvlib:Start Alert Task.vi" (0x3b208ee8)]
SetVIIdle on a previously viBad VI: vi=true

<DEBUG_OUTPUT>
2/16/2025 12:51:19.842 AM
DWarn 0x68CF5A2E: Failed to get DC for drawing.
c:\builds\penguin\labview\components\LVManager\trunk\18.0\source\window.cpp(12353) : DWarn 0x68CF5A2E: Failed to get DC for drawing.
minidump id: ebc20da4-6e57-47f1-9b76-93efb145394d
$Id: //labview/components/LVManager/trunk/18.0/source/window.cpp#4 $

The log shows a ton of these DWarn errors. The last error in the log file is a DAbort.

The messaging class and the Start AMT VI all appear to be fine in the development environment. The application also runs without any issues in the development environment. The application built on the Windows 10 machine runs flawlessly as well. I simply can't get a build on the Windows 2012 Server. This is becoming a major impediment.

Any and all help would be appreciated.

[cbutcher]

I'm not at or near a PC but from your description I'd probably try and track down what's causing the DLL (that's missing on 2012) to try and load.

If you're happy that it works properly in the development environment, I think (but can't check) that you might want to check diagram disable structures or similar (maybe constant false case structures, etc).

I think I remember that the AppBuilder will generally try and load more than perhaps is really required - so if it issue is in a VI you never call, try and get it out of dependencies/linker graphs, and if it's in a disabled case, try deleting it?

Might be miles off base, but that'd be my place to start looking.

[Mark_Yedinak]

---

@cbutcher wrote:

I'm not at or near a PC but from your description I'd probably try and track down what's causing the DLL (that's missing on 2012) to try and load.

If you're happy that it works properly in the development environment, I think (but can't check) that you might want to check diagram disable structures or similar (maybe constant false case structures, etc).

I think I remember that the AppBuilder will generally try and load more than perhaps is really required - so if it issue is in a VI you never call, try and get it out of dependencies/linker graphs, and if it's in a disabled case, try deleting it?

Might be miles off base, but that'd be my place to start looking.

---

This may allow me to run the executable built on Windows 10 on the Windows 2012 Server but it still doesn't explain why the application can't be built on the 2012 server. Plus, there aren't many diagram disable structures in the code. Most of then completely comment out the code which doesn't involve any dll calls. The referenced dll that the 2012 indicates are missing are nothing that my code actually calls. These must be getting called by third party libraries. For the most part this code is pure G code with very limited dll calls. It is also pure software in that it is not using any hardware devices. All interactions with any external devices is done via TCP.