Good Day All, I've got an application where I'm getting intermittent crashes, sometime when in edit mode, sometimes when my program is actually running. I have gotten a couple of "MemoryManager.cpp line 437" crashes, but more often, but still intermittently, I just get the window that says something has happened to LabVIEW and it needs to be terminated. When you click on the more information link it pops up a window that says: "AppName:labview.exe AppVer: 8.6.0.4001 ModName: Unknown ModVer.: 0.0.0.0 Offset 6f636974" This happens when running the application or when editing. It may happen twice in an hour, or after several hours of running. I've watched the memory and thread usage in "Task Manager" and they seem to be stable. The program has two main parts, a UI that at the beginning of the test run uses a .NET call to read back data over the network from the Unit Under Test, parse the returned XML string (using string functions, no "XML parsing" functions from LabVIEW or Windows) and a user interface to start the program. The UI sends a message over a queue to the "Test Engine" which then, depending on the "test recipe" installs and launches the appropriate test program using a "Call by Reference Node". The test program makes measurements of the UUT and saves the results to an Excel file using NI Report vi's from the NI Report Generation Toolkit. The measurements are visa calls to standard "rack and stack" instruments like spectrum analyzers and signal generators. I've done a moderately deep search on the NI site, haven't found anything that looks like the issue, need ideas how to trap this beast and eliminate it. I hope that many of the major players being at NIWeek won't impact the response time. It seems like those years I haven't been able to attend are the ones where I hit a snag like this one. I guess the moral is that I should always attend Thanks in advance, Putnam

LabVIEW

LabVIEW 8.6.1 crashes

Solved!

Solution

Accepted by topic author

Author

Well, while I would be premature to declare success, I have run my stripped down test configuration that seemed to point to the .dll calls when run last week (by regularly crashing). With the help of the hardware's manufacturer providing information about their dll calls I created LabVIEW wrappers around the FTDI USB driver dll, essentially recreating the HW manufacturer's dll, basically taking out the middle man. In doing this I removed a layer between me and the actual executing code, and was also able to then mark the calls to the FTDI d2xx dll as "Thread safe" ("run in any thread"). I used as my template some examples (LabVIEW 7.x version) posted on the FTDI site, but added error chaining, the above mentioned "thread safe" setting, and some "stuff". My test configuration, which runs all of my program, but dynamically loads a "dummy" test, which consists of a set of loops exercising the DIO, has now run for 14+ hours (the cute pattern of LED light changes on the board cheerfully greeted me this morning), where last week in this much more intensive exercise of the DIO it would usually crash within minutes, an hour tops. Others in my extended project team who have been using this DIO with the original dll, but with .NET or other languages, haven't reported any problems, but they also admit that their usage hasn't been nearly as intense as mine, so ...

More "Just For Men" hair coloring to hide the white hairs this one has given me! 😉

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5