I discovered an interesting issue with the LabVIEW 8.6 TDMS Write / Close routine I want to share and document for anyone else unlucky enough to encounter it. In defense of LabVIEW, this issue is only encountered if the programmer uses the TDMS Write and Close out of order (yes, I admit to this). However, in my defense, the error produced by such a 'boneheaded' programming mistake should not abruptly crash your system.
Background:
I was stress testing a large automated testing software package (similar to this Case Study) which we are developing for a Client using National Instruments' LabVIEW 8.6 Developer Suite. The program is fairly large and runs many tests; however, the focus of this testing was on one test routine in particular. This routine samples and processes CAN messages from the DUT (device under test), controls a large power supply and load bank to cycle the product, checks safety and interlock systems, streams data to disk using TDMS, and has to update a pretty complex user interface. One of the advantages of using LabVIEW for this project is the ease of constructing parallel operations for such operations. As such, each of the tasks mentioned above was set in its own parallel looping structure within the testing application.
The Problem:
After running a series of tests over several days, the program was working great... for a few hours. After the program ran for any length of time, I consistently ran into a frustrating error, the dialog box shown in the image above:
"Microsoft Visual C++ Runtime Library: Runtime Error! Program: ...LabVIEW.exe This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information."
The most frustrating part was that I AM THE 'Support Team', and I had no idea what was going on here. All I knew was that my application stopped running.
The Source:
After a few hours of debugging, and some lucky guesswork, I located the source of the bug. After running for an extended period of time, my parallel loops drifted out of sync. Specifically, by the end of a test the main loop would close the handle to my TDMS file before my file streaming loop would write its last data points. Not a good programming strategy.
Not knowing anything about this ahead of time, I would guess that in this case LabVIEW would throw a nice error, which I would have caught and at least had a good indicator of where the problem was occurring and how to fix it. However, the exception is not caught by LabView. Instead you get the mysterious Visual C++ Dialog Box and a crashed application.
Reproducing the Bug:
However, if you run a small program like shown below. You can see for yourself. The program is nothing but a textbook TDMS Open, Write, and Close... followed by a twist, another TDMS Write using the previously closed TDMS reference. Again, not knowing anything, you would think LabVIEW would execute this, but report a nice error out of the error cluster. But instead you get the Visual C++ Runtime Error.
Conclusion:
Simple fix, do not close TDMS reference until you are done with them! Alternatively, NI has a work-around shown here. Or, you could upgrade to LabVIEW 8.6.1 which fixed this issue.
On the other hand, if you ever see a Microsoft Visual C++ Runtime Library Runtime Error Dialog box sitting on your screen where your application used to be, maybe you need to check your TDMS Write/Close order.
Learn more about DMC's data analysis, data mining and reporting expertise.