Troubleshooting LabVIEW Crashes

Updated Nov 14, 2018

Reported In

Software

  • LabVIEW

Issue Details


When I experience a LabVIEW Crash, what are some good troubleshooting steps I can use to diagnose the issue?

Solution

Initial troubleshooting steps for LabVIEW internal errors and crashes:
  1. Send the crash report to NI via the NIER dialog box. Add any relevant information that will aid NI in diagnosing the crash.
  2. Determine if you can reproduce the crash consistently. This will make diagnosing the source of the crash easier. If you can reproduce the crash, then try searching the KnowledgeBase and/or the Developer Exchange Discussion Forums for similar crashes. Include the hex code and what you are doing when the crash occurs. 
  3. Install the latest update or patch of LabVIEW. 
  4. Check the Known Issues list for your LabVIEW version.  
Further troubleshooting steps:
  • Try to narrow down the source of the warning. Reduce down the code and the amount of hardware used to create the smallest reproducing case of the crash. If you can eliminate the parts that are not related to the crash, it is more likely to find the root cause of this specific crash. Please see the following troubleshooting steps to help in doing this:
    • If the crash happens with an executable, check if the same behavior occurs when running the VI from the LabVIEW development environment. Doing this may point to an issue with the Run-time Engine.
    • Try using diagram disable to disable parts of your code. This can help us narrow down where in your code the crash is happening.
    • Try removing all hardware, if you still see the crash then we can continue troubleshooting the software. If removing the hardware fixes the crash, then we can narrow the cause to the hardware. Try using a different kind of hardware to see if the crash is specific to the type of hardware.
    • Check if you see the same behavior on a different computer. The crash have something to do with the environment of the computer.
    • Monitor memory to check for memory leaks.
  • Use WinDbg to troubleshoot the crash. If the crash is reproducible, then attach this tool to the LabVIEW process and cause the crash to happen again. This tool can give you a more in depth look at the source of the crash. 
  • If you are using hardware be sure of closing every reference of the instruments, any misuse of the references could cause a memory leak.
  • Make sure that all the error clusters are connected and being monitored. An error may have occurred earlier that you are unaware of. Error numbers are there to specify what went wrong and can be searched for in the Explain Error dialog box (Help»Explain Error...). Here you can find an explanation about the error and you have the option to search ni.com for the error number.
  • If you are using .NET framework or DLLs, try removing them to see if the crash still happens. The DLL could be where the crash is happening.
  • If the crash occurs consistently with just one VI, try copying the entire contents of the block diagram to a new VI. Sometimes this can remove corruptions that can cause crashes. 
  • Mass compile your VIs (File»Mass Compile or Tools»Advanced»Mass Compile, depending on your version of LabVIEW). If you upgraded LabVIEW from an earlier version, you may have some older VIs that were not updated. Go to LabVIEW Help: Mass Compiling for more information. 
  • The crash could also be happening because of an "Insane Object" or "fsane.cpp" error in your code.  
  •  Look at the LabVIEW Error Log, or the Real-Time Error Log if dealing with a Real-Time system.

The goal is to narrow down the root cause of the error. Once the cause is known the next step is to find a work around as well as reproduce the issue on the smallest scale. If it is a LabVIEW bug, then a Corrective Action Request (CAR) can be filed by National Instruments Technical support. 


If you still encounter a LabVIEW internal error after following these suggestions, contact National Instruments Technical Support. Attach an example VI that demonstrates the crash, so that our Applications Engineers can more easily diagnose the problem. It is also recommended to send them your.dmp files related to the crash. Providing this file to National Instruments may give further insight to why you are experiencing the crash. 
 

Additional Information

What is a LabVIEW internal error?

A LabVIEW internal error is an indication that something wrong or unexpected has occurred within LabVIEW. Depending on the level of severity, you may receive an error dialog immediately or possibly later, when you exit or restart LabVIEW.
The three severity levels are DAbort, DWarn, and DWarnInternal.
A DAbort is unrecoverable and LabVIEW exits immediately. This avoids possible further corruption and you will see a Crash Report dialog similar to the following:

DWarns and DWarnInternals are recoverable errors and will not cause LabVIEW to exit but they are still unexpected and need to be reported. You may see an Internal Warning Report dialog when exiting from LabVIEW, depending on your LabVIEW settings.

These crash and internal warning dialogs are part of NI Error Reporting or NIER. NI Error Reporting, or NIER, allows you to send National Instruments a crash or internal warning report. You can attach relevant files, comments, and your email address to the crash to internal warning report. 
 

WAS THIS ARTICLE HELPFUL?

Not Helpful