Current Position:Home > LabVIEW 8.6.1 crashes

LabVIEW 8.6.1 crashes

Update:10-11Source: network consolidation
Advertisement
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
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion
Solved!
Go to Solution.

The Best Answer

Advertisement
Looking at this specific error, LabVIEW's memory manager has decided that a memory handle is invalid. One case in which this can happen is when different versions of LabVIEW are in use simultaneously and a data handle is passed from one version of LV to another. One such scenario would be:
LabVIEW 2009 calls the function 'myFunc' from 'foo.dll'
'foo.dll' was built using LabVIEW 8.6
'myFunc' expects an array of data, passed as a LabVIEW array handle
The problem arises in this case because the array handle allocated by the LabVIEW 2009 instance of the LV memory manager is sent to a VI running in the LabVIEW 8.6 Run-Time Engine, which has the LabVIEW 8.6 version of the memory manager. Because the data is an array handle, and LabVIEW may need to resize the handle, the code in the LV 8.6 Run-Time inspects the data handle to see if its memory manager considers it a 'good' memory handle (i.e. one that it allocated itself). It discovers that the LV 8.6 Run-Time didn't allocate the handle, and, being mistrustful of data from other memory managers ( ;-) ) it has no choice but to abort the application. It's either that or corrupt memory.
In such cases, a workaround is to pass array pointers (or strings) that cannot be resized -- an unsavory situation if the underlying implementation must resize the array (or string). The workaround in that case is more complex - e.g.. having two functions - a 'preflight' that tells you how big the output will be, and the 'actual' function that requires a properly sized output buffer.
For more complex data structures (e.g.. clusters) the workaround is to break apart the cluster into individual, simple types that can be passed as pointers to data or simple scalar values.
Whether this is at all similar to your case is unclear - it sounds like there are several component layers involved with different technologies. But the crash itself is still that LabVIEW 8.6 has gotten a memory handle from somewhere that's *not* been allocated by the LabVIEW 8.6 memory manager.
One thing you could do with Process Explorer and similar tools is determine if there are multiple versions of LabVIEW in the main process. For example, if both LabVIEW.exe and one or more lvrt.dll instances from different locations on disk are in memory, you've found a red flag. The quest then is to find out which components in your software stack are responsible for bringing in those different versions of LabVIEW, and how they're interacting via code.
Best regards,
intvsteve
LabVIEW R&D
  • LabVIEW 8.6.1 crashes Update:10-11

    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 stil

  • Labview 5.1 Executable crashes when I try to run it a second time Update:11-30

    I created an executable from some labview 5.1 code I wrote. The code works fine when I run it under labview, but when I created an executable, the code crashes. I can run the code once and it will work fine, but when I try to run it again it crashes.

  • LabVIEW 2010 in-placeness crash bug Update:11-30

    [cross-posted to LAVA] I found an odd LabVIEW 2010 bug that will cause a hard crash. The bug appears to be related to how LabVIEW operates on data in-place and some interaction between clusters, arrays, and the Aum Array Elements node. It's hard to d

  • Labview 2012 Runtime Application Crash: Access Violation Error Update:11-30

    hi All, my rather large app that I been develping over teh last few years has recently been crashing. I do not know if it is since I began compiling it in LV2012 SP1 that the problem occurred or I have some programming error that I cannot track down.

  • LabVIEW 2012 f1 Patch crashes Update:11-30

    I've just installed LabVIEW 2012 and unfortunately I've already run into some troubles. I received a "Setup has stopped working" when I installed the device drivers.  But the installation appeared to be fine.  LabVIEW started and MAX would open.

  • Labview 8.5 project crashes when searching for callers of missing lvlib Update:11-30

    I have done a search and reviewed previously reported crashes with LV8.5, but did not find a match to what I'm seeing. SYNOPSIS: When selecting Find > Callers, under the project Dependencies, LV crashes as shown in the image below. I created a new pr

  • LabView starts ok but crashes when try to open "block view" Update:11-30

    I'm running LabView 7.1.  It has been operating fine.  But all of a sudden it starts crashing.  I can start LabView.  But as soon as I have opened a module and try to run it, it crashes.  Sometimes it also crashes when i try to open the "block view&q

  • Labview 2011 FDS (64bit) crashes when saving a vi with MATLAB node Update:11-30

    After running a vi which includes a MATLAB node, the vi cannot be saved, because Labview crashes every time with error: "DAbort 0x1A7102DF in fpsane.cpp". Why does a MATLAB node with simple array I/O corrupt LABVIEW's sanity ??? I have attached

  • LabView 8.5.1 crashes at splash screen "appentrypoint.cpp, line 74 error" Update:11-30

    Been using it for a while.  Updated to lv2011 but need to be able to still use 8.5.1.  After upgrading found out the earlier version is not compatible with the fieldpoint 6.0.10 drivers that updated my 6.0.1 version.  So, I uninstalled the 2011 LV an

  • Labview 7.1.1 crash on right click of subvi Update:11-30

    We've started having a problem on one computer, with a 3.4ghz, Intel dual core motherboard, win XP pro. When a subvi, usually homemade, and begun under an earlier version of labview, is right clicked in the diagram, we get a dialog stating that "Labv