• Mass compile

• Log files

  • found in <%temp%> (eg C:/Users/username/AppData/Local/Temp)
  • 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

• If .exe build breaks (especially on RT)

  • check if any conditional disable structures contain broken code

• Application Builder comes with a logging feature. The logfile gets placed alongside the .lvproj with an autogenerated name.

  • Some app builder issues stem from the VIs becoming broken when they are copied into the EXE. Using the INI token to get the state of the copy during the build can tell you when this is happening and which VIs specifically are breaking during the build.
  • To enable it, add the following to the LabVIEW.ini file:

  NI_AppBuilder_Logging=TRUE
  NI_AppBuilder_CheckVIState_Copy=TRUE

• 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

• Manually delete the compiled object cache files:

  • First: User file at [LabVIEW Data]\VIObjCache\[version]
  • Second: LabVIEW core object cache at [LabVIEW 20xx]\VIObjCache
  • (tip courtesy of Darren N.)

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

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:

  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“