Troubleshooting Crashes/Hangs in large applications with the Crash Logger.vi

製品と環境

このセクションは、サンプルの作成に使用された製品およびOSを反映します。

以下に示された製品を含め、NIのソフトウェアをダウンロードするには、ni.com/downloadsをご覧ください。

    ソフトウェア

  • LabVIEW

コードとドキュメント

添付

Description

Overview

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.

Description

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:

  • Track processes within a program
  • Write to a text file to keep track of location within an application while running
  • Write to a text file to track system resources at particular points in time.

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.

 

State Example.png

 

NOTE: Crash Logger.vi doesn’t work on MAC OS even though it has an option for it.

Hardware and Software Requirements

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!

Steps to Implement or Execute Code

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.

 

 

 

Regards,

Ben Johnson
ʕง•ᴥ•ʔง

NIコミュニティのサンプルコード交換のサンプルコードは、MIT Licenseによりライセンス供与されています。

コメント
RandallCrandall'sCandleHandle
NI Employee (retired)

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:

  1. The main VI needs a comment on the front panel with Overview/Requirements/Instructions
  2. You need to run the VI analyzer and make sure most of the standards are upheld. Things like misspellings on the system commands and the large window size are not a problem.

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

TheEngineeringBear
Active Participant
Active Participant

@RandallCrandall'sCandleHandle Passed VI analyzer with flying colors and finished all other updates requested.  Ready for posting!

 

-Bear

Regards,

Ben Johnson
ʕง•ᴥ•ʔง
nanocyte
Active Participant
Active Participant

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.

TheEngineeringBear
Active Participant
Active Participant

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

Regards,

Ben Johnson
ʕง•ᴥ•ʔง
TheEngineeringBear
Active Participant
Active Participant

Updated to v3:

- Addressed Sys Config issues on Windows 10

- Addressed performance issues 

- Cleaned up and minimized block diagram size

Regards,

Ben Johnson
ʕง•ᴥ•ʔง