To download NI software, including the products shown below, visit ni.com/downloads.
This VI is used to help trouble shoot crashes/hangs by taking advantage of System Configuration VI’s to log location and system resource usage.
This is a VI that has been written to help LabVIEW users troubleshoot their code when having problems with large applications. It is intended for crash and hang troubleshooting but can also be used to:
First step in trouble shooting any crash is to find out what is causing the crash and simplifying code to make a reproducing case. This VI would be used to help narrow down where crashes/hangs are occurring, if there are CPU spikes and if memory leaks exist within the application. The idea behind the VI is that you should be able to narrow down what the last state is before the crash and/or what the resource status on the target looks like during run time.
NOTE: Crash Logger.vi doesn’t work on MAC OS even though it has an option for it.
LabVIEW 18-20
Included is the LabVIEW 2018 version of the VI and a Project to demonstrate how it is used if needed. If you need a previous year hopefully someone can post it for you!
Crash Logger.vi is self-contained, requiring no special driver, as all it uses is File I/O and System Configuration API to write the Current Location of the VI and various host (Windows PC or Real Time Target) information. The text file it creates is “State_Tracker_Log.txt” and should be located where you saved the project for a Windows application. For Real Time OS’s, the file will be in locations “C:” for Pharlap ETS targets, “c:” for VxWorks targets and “home:\lvuser” for Linux targets. You will have to either use NI Max to view the files or use FTP to pull the files off the RT target. If you don’t pull the file off after each run the text will be over written from run to run.
To use the “Crash Logger.VI” you simply need to drop the VI into locations of your code you would like to keep track of within your application. You then attach a string of where you put the VI (i.e. “Application Begin”) and choose what type of log you would like to perform using the enum. Then attach the error wires to your code (because we all error handle) and run your program. The text file is written to specific locations depending on your OS. You can see from the Crash Logger.vi block diagram where it logs to depending on what OS you are running the VI on.
Attached to this example is a project that has a simple state machine that shows how the VI can be used to track State’s and resources.
Note - If you save the .txt file to Windows and open it in Notepad it will be one long string with no Return Carriage's being acknowledged. To get around this simply open with Notepad++ or Wordpad.
What Operating System Is My Real-Time Controller Running and Why?
Memory Reporting Issue with NI Linux Real-Time OS Targets
Obtaining a WinDbg Dump File to Troubleshoot Crashes in National Instruments Software
Description-Separate-2
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
Hey Ben,
This is an awesome example! I'd like you to take a look at our style guidelines and make sure that your VIs adhere to them:
http://forums.ni.com/t5/Using-the-NI-Community/Example-Programs-Style-Guidelines/td-p/3368050
The main areas that I saw are that:
I also think it would be fine to submit one version that is saved for LabVIEW 2014 instead of 3 different versions in order to simplify things.
Cheers,
Ryan
@RandallCrandall'sCandleHandle Passed VI analyzer with flying colors and finished all other updates requested. Ready for posting!
-Bear
I have a couple warnings:
Resource check takes ~2 seconds on my PC. That could really slow things down depending on what you want to log.
Also, you're writing to the application directory which works well in the development environment but if you were to build it and distribute it in an installer, on Windows 10, you'll have no write permissions for the Program Files folder and you'll get an error 8.
In my bench marking I was only seeing ~50 ms of overhead (Windows 7) with the crash logger so it must be system dependent. Also, it is designed to be a shared resource so beware of race overhead as well. However, I make no claim that this does not affect performance. That's an unfortunate downside of troubleshooting, have to change something to measure an effect.
Here are some recommendations I have:
1. Include Crash Logger in applications from the beginning of development in order to account early on for added overhead. You will also then have immediate logs for when issues arise.
2. Crash Logger is a malleable tool, change it to meet your needs.
-Bear
Updated to v3:
- Addressed Sys Config issues on Windows 10
- Addressed performance issues
- Cleaned up and minimized block diagram size