• Mass compile
• Forcing a VI to Recompile (Ctrl-Shift Run)

• found in Windows' temp folder (eg C:/Users/username/AppData/Local/Temp)

  • Simply enter %temp% into your Windows Explorer address bar
  • Look for files named LabVIEW or your .exe's name

• Current run

  • named with LV bitness, version, username (eg LabVIEW_32_18.0.1f4_username_cur.txt)
  • recreated for each new start of LabVIEW
• Broken VIs

  • named with timestamp (eg LabVIEW_BrokenVILog_2021-03-04T120841.txt)

• Enable detailed debugging

  • controls how much information goes into the log files (see above), the log files are created with some content either way
  • add the following to the LabVIEW.ini file:

  labview.debugging=True

• „Since it's a crash, you'll be looking at the end of the file, as I mentioned. You'll be looking for things like DAborts, DWarns, Exceptions, etc. Sometimes those failures will include useful info, like the name of the VI that was being loaded/unloaded when the failure happened.“ (D. Nattinger)

• A compiled object cache is the location where LabVIEW stores the compiled code for the following kinds of files:

  • VIs and other file types that have separate compiled code
  • VIs that you deploy to an RT target
  • VIs that compile when you build a build specification

• Manually delete the compiled object cache files:

  • First: User and LVAddons caches at (*)

    • [LabVIEW Data]\VIObjCache\[version]
    • [LabVIEW Data]\AppBuilderCache\[version]
  • Second: LabVIEW core object cache at

    • [LabVIEW 20xx]\VIObjCache
    • (tip courtesy of Darren N.)

(*) [LabVIEW Data] usually lives in the user's Documents folder.

• Class mutation history can become an issue and can be cleared

  • see Slow Editor Performance with Large LabVIEW Projects Containing Many Classes
  • more about Preserving LabVIEW Class Data

See Application Builder and Build Specs.

• Clearing the compiled object caches should always be the first step

• Check if any Conditional Disable Structures (CDS) contain broken code

• If you're using malleable VIs (.vim) with LabVIEW classes as defining data types, clear the class mutation history (see above)

• If LabVIEW crashes during building, double-check the “Additional Exclusions” page. If you have “Remove unused members of project libraries” is checked, then sometimes it helps to uncheck the “Modify project library file after removing unused members” option.

• Double-check the dependencies in the .lvproj

  • Make sure no unwanted resources have been pulled into the codebase
  • No Test-VIs being cross-linked
  • No VIs from wrong folders

Error 42 is a LabVIEW generic error so it can mean several different things. While generating an executable it can mean that some of the files in the project or the project itself is corrupted. Possible remedies include mass compiling or setting the following .ini key:

  NewAppBuilderCache.Enabled=False 

Error messages along the lines of “A LabVIEW file of that name already exists in memory, or exists within a project library already in memory. Method Name: Library:Open” hint at problems with the AppBuilder cache. This can be related to using webservices or MediaMongrel's Websockets library (Bug 2914772, source), or building packed project libraries (.ppl).

The following .ini entry might help:

  NewAppBuilderCache.RemoveLibraryReferences=False

If that does not effect any changes, consider this approach:

  NewAppBuilderCache.Enabled=False

For LabVIEW 2024Q3 or later, building a PPL can fail with error 1502 due to error rings being used (Bug 3076504). Instead of removing all error rings, you can set the following .ini key:

  NewAppBuilderCache.Enabled=False 

If you change the icon for your application but Windows Explorer does not show an updated .exe icon, this could be due to the Windows Icon Cache not updating properly. You can delete the cache, forcing Windows to rebuild it.

Some app builder issues stem from VIs becoming broken when they are copied into the EXE. Application Builder comes with a logging feature that lets you get the state of the copy during the build, which can tell you when this is happening and which VIs specifically are breaking during the build.

To enable logging (the logfile gets placed alongside the .lvproj with an autogenerated name), add the following to the LabVIEW.ini file :

  NI_AppBuilder_Logging=TRUE

The NI_AppBuilder_CheckVIState_Copy ini token adds the following: “If app builder logging is enabled, after every source file is processed, check exec state of all VIs in memory and log any broken VIs.”

  NI_AppBuilder_CheckVIState_Copy=TRUE

Add the following to the LabVIEW.ini file to keep the intermediary files as a .zip archive, which is useful if things are broken after building (disable the “Use fast file format” option in the “Advanced” section of the build specification so LabVIEW creates the intermediary archive):

  NI_AppBuilder_KeepInternalLlb=true

Mass compile will sometimes show broken VIs due to insane objects. You can use Ned (see below) to save the VI in XML format to try and identify the insane object and then potentially fix it.

Reasons for insane objects might be cluster elements with empty labels or incorrectly linked type definitions.

• See Networking.

• Automatic Saving for Recovery

  • In the event of an irregular shutdown or system failure, LabVIEW backs up any modified files open at the time of the shutdown or failure to a temporary location.
  • LabVIEW stores backed up files in the LVAutoSave subdirectory of the default data directory.

• Rename LabVIEW.ini and see if an errant token is causing the crash

• Disable/uninstall any VI Packages, plugins, providers, menu tools etc. that might have to do with the crashes

• If LabVIEW crashes immediately when starting, watch the splash screen to see how far it gets.

  • This might be related to an issue with Antidoc.

• Repair LabVIEW in NI Package Manager

  • VIPM Runtime Engine - Installation Media Required for Repair
• Try force-reinstalling LabVIEW

• Access Violation 0xC0000005 Crash When Starting LabVIEW

  • “I've seen issues where Windows Defender gets a little busy and causes problems. Maybe try adding C:\ProgramData\JKI\VIPM and your LabVIEW installation locations into the Windows Defender exclusion/exception list so it doesn't do Real-Time protection/scanning of those locations.” (Jim Kring, Discord)

On some machines, LabVIEW takes a very long time to start up - it seems to hang at the splash screen

• LabVIEW or TestStand Starts Slowly When Not Connected to the Internet
• LabVIEW or LabWindows™/CVI Taking a Long Time to Launch
• LabVIEW Is Starting Very Slow After Hard Shutdown of the PC
• License Manager Logging

For certain LabVIEW versions and project constellations LabVIEW will not remove all project resources (ie VIs) from memory when closing the project window. Instead, it will ask to save resources afterwards when closing LabVIEW itself.

It is unclear at the moment what exactly triggers this. We suspect it might have to do with targets as we've seen this mostly on RT/FPGA projects.

See the following forums discussions:

• https://forums.ni.com/t5/LabVIEW/LabVIEW-Bug-When-Sharing-Module-Timebases/td-p/3895817
• https://forums.ni.com/t5/LabVIEW/Vi-stays-open-after-closing-the-project/td-p/3838922/page/2

• Closing References in LabVIEW

Technical Support Report for NI

• http://digital.ni.com/public.nsf/allkb/271F252B4EF0A2E0862570E70056A1E4

LabVIEW has a few built-in yet hidden debug features. These can be enabled by putting the key LVdebugKeys=True in your LabVIEW configuration file.

• A window with list of debug-related private or internal options
• Press CTRL+SHIFT+D+N (CTRL-SHIFT-dot-N on German keyboard)
• More: https://labviewwiki.org/wiki/Ned_options

• allows to view internal data structures created for all loaded VI files
• Press CTRL+SHIFT+D+H (CTRL-SHIFT-dot-H on German keyboard)
• More: https://labviewwiki.org/wiki/Heap_Peek

To ensure NIER collects the most useful information, you need to set a few INI keys on the process that is executing the LabVIEW code. If the user is using the LabVIEW Development System, these keys should be set in the LabVIEW.ini file located in the LabVIEW directory in Program Files. If the user is using the LabVIEW Run-Time Engine from within the TestStand Sequence Editor or a TestStand user interface, these keys should be set in a [LVRT] section (create it if it does not exist) within the <name of executable>.ini file next to the TestStand executable.

INI keys:

  debugging=True
  NIER=True
  NIERDumpType=full
  LVdebugKeys=True
  DWarnDialog=True
  DPrintfLogging=True
  promoteDWarnInternals=True

Of these keys, you should always set the NIERDumpType=full key when debugging an issue, because this key will cause a larger crash dump with more debugging information to be created. This is what we colloquially refer to as a “full crash dump”. The other INI keys can be used to gather more information, but they have the caveat that they will slow execution of the code down, which can be a problem for certain types of issues.

It is also important to note that when NIER creates a full crash dump, it should not be submitted to NI through the NIER crash dialog. The NI system is not prepared to handle crash dumps as large as those generated by NIER with the INI key enabled. Instead, the customer should use our FTP site to send us these files. Additionally, the INI key should be disabled once the issue is resolved.

http://digital.ni.com/public.nsf/allkb/7E9EBE4CA3B6DCE786257633005E7121

• Taskmanager „GDI-Objects“

Sometimes, even though trying to find some relevant information in Google or NI Community forum, it is just hard to get the explanation and solution for the given problem. Here is the list of various resources which can be treated as a last resort option - they can help or just be a fun fact for the future:

• Ludicrous Ways to Fix Broken LabVIEW Code by Darren Nattinger - https://bit.ly/ludicrouslabview