• 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

• 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 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.

See Application Builder

• check if any conditional disable structures contain broken code

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

  • read more about Preserving LabVIEW Class Data

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:

  NI_AppBuilder_KeepInternalLlb=true

Mass compile will sometimes show broken VIs due to insane objects. You can use Ned 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

Technical Support Report for NI

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

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:

  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“