Labview crashing when building executable

[AdarshaPakala]

Hi,

My LabVIEW application is pretty big size(loads more than 7000 vis when opening the project) and built on Actor framework.

The project doesn't have any file conflicts and missing VIs, runs very fine in the development mode. When I try to make an executable it is crashing or freezing the LabVIEW(most of the time crashing, see below screenshot).

I was able to build the executable a couple of months ago without any issue, later that I have added 3 more actors to the project to add some other features. I have not changed anything on the build configuration apart from the version number.

The build process is crashing when it progresses around 50% Refer bellow screenshot which was taken little before the crash.

What could be the reason and how can I tackle  this issue? Any comment will be helpful.

Environment:

• LabVIEW 2016 32bit
•  Windows 10 64 bit
• Memory min 8GB
• Virtual memory is set around 6GB for C drive and Source code drive.

I have tried following;

1. Clear Compiled Cache => load the project => Save All in the project => Close project and Restart the computer => Load the project again => Start the build - No Success
2. Mass compile the project top level folder Load the project again => Save All in the project => Start the build - No Success
3. Try in different computers(with same LabVIEW configuration) - No Success

Thank you

Adarsh

LabVIEW from 2006

CLA from 2014

[Bob_Schor]

Sounds like you might be "running out of room".  One thing I noticed is you say you have 8 GB of RAM, and when I "asked Google" how much Virtual Memory you should have, they said between 1.5 and 3 times the amount of physical RAM (or 12 to 24 GB, not 6 GB).  I also noticed that you seem to have 67% of your memory committed with about 50% of the build completed -- who knows how much adding your three Actors contributes to the Memory requirements.

Bob Schor

[tst]

Debugging build issues can be tricky.

The "correct" answer is probably to say that at that size you should refactor your app into separate builds (for example, using packed project libraries), so that each build is simpler.

Barring that, here are a couple of options which might help with debugging the issue:

1. Add logging to the build (there's a checkbox for enabling a build log in the Advanced page of the build settings and you can add this to LabVIEW.ini: NI_AppBuilder_Logging=True). This log is not meant for you, so getting useful information from what you see there is far from guaranteed, but it's very easy to at least check.
2. Disable/delete parts of the code and see where the problem starts happening. Luckily, you don't actually need a functional app, so you only need to make sure it's not broken.

[AdarshaPakala]

Thank you so much for your reply!

I have changed the virtual memory to around 18GB, running the build again.It will be an interesting study.

[AdarshaPakala]

Thank you so much for your reply.

I will try enabling the build log.

[AdarshaPakala]

After increasing virtual memory to 18GB+, the LabVIEW is not crashing but, I get this error now.

[Kyle97330]

The first screenshot showing a crash in drawmgr.cpp means that it could be a problem with the GDI object limit:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7OGSA0&l=en-US

Per that article you can try to find ways to lower the amount of objects you use, or raise the amount Windows allows, and see if that helps.

[AdarshaPakala]

Thank you so much for the inputs!

After so many experiments, I could catch the GDI object count number when its about crashing, I could see its reaching 10,000.

Now I'm testing it by increasing the Windows 10 GDI objects limit(set to 3x, i.e 30,000). I'll post the outcome.

I have following questions;

1. What are the effective ways to lower the amount of objects ? Delete unused FP controls and indicators ?
2. Is using property nodes with reference input in sub vis create a graphic object when that VI is compiled/run ?

[Kyle97330]

The GDI count is a factor of both your program AND of your LabVIEW dev environment.  One of the things that can take up a lot of them is the size of the things in your palettes.  LabVIEW automatically scans your user.lib and instr.lib folders and loads those in the palettes, so if you can remove things from there you don't need that can help without having to trim your program's size.

While deleting front panel controls will reduce the count, it won't reduce it nearly as much as removing files from your libraries that you don't use.

[AdarshaPakala]

Thank you for the information.

Further developments;

now the build is crashing with different error.

Translation of the error message is;

We apologize for any inconvenience

There was a problem in LabVIEW 2016. The program must be closed. To help identify the cause of the problem, please send this log to National Instruments. Exception: Access violation (0xC0000005) at EIP=0x0FF0AA7A Version: 16.0f2 (32-bit)

Last error logged in lvlog.txt is;

 

Last paragraph in the above screenshot:

Not enough memory to complete this operation.

<DEBUG_OUTPUT>
25.09.2022 07:29:38.404
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: b68405fc-6c86-4bd3-ac5e-90972bc26c41
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x100011AF - nierInterface <unknown> + 0
0x10005F5A - nierInterface <unknown> + 0
0x100062EC - nierInterface <unknown> + 0
0x745935DA - mscoreei <unknown> + 0
0x773CD9D2 - KERNELBASE <unknown> + 0
0x77DDDE77 - ntdll <unknown> + 0
0x77DA1F34 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0