Troubleshooting LabVIEW Crashes

Issue Details

• While navigating the LabVIEW Development Environment, LabVIEW crashed and displayed the following error: LabVIEW 20xx encountered a problem and needs to close. You can help us diagnose and fix this problem by sending this report directly to National Instruments.

• LabVIEW crashes with no errors when I close a VI that I have created. 
• LabVIEW crashes with no errors when hovering over items in a project after updating Windows 10 to version 21H2. 
• My LabVIEW executable crashes when I try to run it. 
• How can I find the cause for my LabVIEW crash?

Solution

Initial troubleshooting steps for LabVIEW internal errors and crashes:

1. Send the crash report to NI via the LabVIEW Crash Reporter 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 the NI Community for similar crashes. Include the hex code and what you were doing when the crash occurs.
3. Install the latest LabVIEW patch.
4. Check the LabVIEW Known Issues list for your LabVIEW version from the LabVIEW Release Notes page.

Further troubleshooting steps:

• Try to fully shut down and restart the affected machine before trying subsequent steps.
• If you are using Timed Structures on non-deterministic environments like Windows, substitute them with regular (non-timed) structures. 
• If you updated Windows 10 to version 21H2, try to repair the LabVIEW installation .
• Sometimes when you press any combination of keyboard keys or keyboard keys with the mouse it causes Windows to run some third party software that could cause LabVIEW to crash.
• Monitor the memory usage of your application using Tools for Measuring LabVIEW Memory Growth. If a memory leak is detected in your VIs, try to reduce your memory usage by applying some of the steps mentioned in Memory Is Full in LabVIEW, additionally, you can add the Request Deallocation Function  to your code to deallocate unused memory, in some cases it can improve memory performance.
• Another alternative is using the Monitor Execution Time and Memory Usage in LabVIEW VIs in order to find any presented memory leaks.
  • If using hardware, ensure that you are closing every memory reference. Any misuse of the references could cause a memory leak.
• Make sure that all the error clusters are connected and 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...) to find an explanation about the error.
• If the crash occurs consistently with just one VI, try copying the entire contents of its Block Diagram to a new VI.
  • This can remove corruptions that can cause crashes.
• If the crash is occurring in an executable, ensure all necessary drivers are installed on the deployment machine.
• Mass compile your VIs.
• If you upgraded LabVIEW from an earlier version, you may have some older VIs that were not updated.
  • Mass compile your VIs.
  • If you are using NI hardware and legacy drivers like Traditional NI-DAQ, the crash could be caused by VIs that are not compatible anymore in newer versions: Transition from Traditional NI-DAQ (Legacy) to NI-DAQmx in LabVIEW .
  • If the LabVIEW version you are upgrading from is too old compared to the one you have (for example jumping from LabVIEW 7 in Windows XP to LabVIEW 2015 SP1 in Windows 10), gradually try to use other LabVIEW versions closer to the old one (for example LabVIEW 8, LabVIEW 2009, etc) and check if the VI opens there. If it works, save the VI and move to a newer version until you get to the one desired. Sometimes this can help the newer LabVIEW version compile old code and let adjacent versions automatically fix potential issues. Mass compile your VIs if the VI crashes any of the versions tested. 
• Turn off the firewall and try to run your project.
  • Some antivirus software, such as SentinelOne, contain DLLs that cause LabVIEW to crash. 
• Ensure you are not exceeding the maximum size of the block diagram or front panel. 
• If you are using VIs from any Modules or Toolkits, try reinstalling them as it is possible they are corrupted. 
• 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.
• The crash could also be happening because of an "Insane Object" or "fsane.cpp" error in your code.
  • To check this, look at the LabVIEW Error Log, or the Real-Time Error Log if dealing with a Real-Time system.
• Implement your own logging to gain more information on where the crash may be occurring.
• 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.
• Try to narrow down the source of the warning.
  • Reduce 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, you are more likely to find the root cause of this specific crash. Please see the following troubleshooting steps to help in doing this:
    • Avoid using classes inside Libraries, if this is the case, move the classes out of the libraries.
    • 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 LabVIEW Run-Time Engine.
    • Try using a Diagram Disable Structure to disable parts of your code. This can help narrow down where in your code the crash is happening.
    • Try removing all hardware. If you still see the crash, then you can continue troubleshooting the software. If removing the hardware fixes the crash, then you 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 could have something to do with the environment of the computer.
• It's possible that the issue is related to a corruption of the software or even the operating system. If you've tried the troubleshooting steps mentioned above and were unable to resolve the problem, consider reimaging the computer. 
• If the root cause of the crash can be determined, the next step is to find a workaround or reproduce the crash on the smallest possible scale. If it is a LabVIEW bug, then a Bug Report can be filled out by contacting NI Technical Support. Attach an example VI that demonstrates the crash as well as any supplementing files obtained from the above steps. This will help our Technical Support Engineers replicate and best understand the problem.

Additional Information

What is a LabVIEW internal error?

• A DAbort is unrecoverable and LabVIEW exits immediately.
  • This avoids possible further corruption and you will see a LabVIEW Crash Report dialog box similar to the one above.
• DWarn and DWarnInternal 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 box when exiting from LabVIEW, depending on your LabVIEW settings.