LabVIEW 8.6.1 crashes

[LV_Pro]

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

[LV_Pro]

I look at the XP event log and it doesn't clarify anything, just an error 1000, with essentially the same info mentioned above. Strained through everything I can find on this site without any break throughs. Any thoughts on how catch the error, what to look for.

[LV_Pro]

This is getting really annoying. Had two crashes, one while running, one while editing. Both the same "no explanation" (like MemMgr.cpp or similar) just a pop window stating that something has happened to LabVIEW and it has to be shut down.  

Help me Obe Wan, you're my only hope!

[LV_Pro]

It ran 12 hours last night before it crashed, but only 6 minutes between two crashes before that. Not sure what is going on or even how to try and determine the offending problem. I had been runnning it on my personal work laptop, moved it to our lab laptop a week ago, crashes on both. So unlikely it is the LabVIEW installation, specific computer hardware, etc. It does have yet another .dll that it calls rather frequently, so I am looking t that as a possible culprit. Just don't know what tools to best trap the problem. It is a low level crash, doesn't pop up the standard "LabVIEW crash" screen, doesn't store a LabVIEW lvfailurelog file entry. I does show up in the Microsoft event file, but gives very little info.

[Ben]

---

@LV_Pro wrote:

This is getting really annoying. Had two crashes, one while running, one while editing. Both the same "no explanation" (like MemMgr.cpp or similar) just a pop window stating that something has happened to LabVIEW and it has to be shut down.  

Help me Obe Wan, you're my only hope!

---

Since the other Bens are at NI Week I'll try to hlep.

This KB may be helpful. For your case it is trying to point at external code and possibly the thread it runs in.

I don't remember the exact name but MS has something called Process monitor that you can configure to log all calls by all processes running.

since it happens at edit as well as run time, I don't think the Execution trace toolkit will get you anywhere.

Jsut trying to help,

Ben

[LV_Pro]

Thanks Ben. Unfortunately these are low enough that I don't get the LabVIEW detected error message, more of a Windows "You app crashed" type. At least it doesn't ask me if I want to let it phone the mother ship.  Got a call from another of your associates a little bit ago (MP) about the problem and we discussed my recent discoveries. In going through the code with a fine tooth comb, focusing on those parts I didn't write ;-), or at least those that would be more likely to cause low level crashes, I found a place where there were some .dll calls for a USB driver for an "off" brand DIO card. I don't know if the dll wrapper was created by a developer here or delivered from the HW manufacturer but I found that 4 of the five calls used the "stdcall" convention, the 5th (a close) using the "C" convention. Don't know if that is the cause, but suspect that it very well could be, won't know if it fixed it until the program has had an opportunity to run for a solid day or so. Hate intermittents that don't provide good crash info.

Thanks as always!

P

[Ben]

---

@LV_Pro wrote:

Thanks Ben. ...Hate intermittents that don't provide good crash info.

Thanks as always!

P

---

There is very little you can say about intermitant problem except...

1) They never fix themselves.

2) You can not say you have fixed or even entertain the possiblity until at least 4 times the max interval between failures has transpired.

3) They are paranoid little critters that don't like you talking about getting them "fixed".

Ben

[Greg_J]

Hi Putnam,

I found an obscure instance of the MemoryManager.cpp Line 437 error stemming from an incorrect DLL call.  In one case, when using a Call Library Function (CLF) Node to call a LabVIEW-built DLL returning an array, the user observed a crash at line 437 if the DLL expected an array handle pointer and the CLF Node was set to take an array handle.

This may not apply, but it was the closest reference I could find to your suspicions.

- Greg J

[intvsteve]

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,

[LV_Pro]

Not really seeing the Memorymanager errors, saw a couple early last week, but have been mostly having what I'm pretty sure is a Windows (XP) window popup telling me that something has happened with LabVIEW and it is being stopped. Click on the embedded link and it just says that there was a problem with labview.exe, Module: unknown, etc. It turns out it is the same information that is in the Windows Control Panel:Administrative Tools:Event View:Application, which is basically nothing. LabVIEW, upon restart, knows it wasn't shut down properly, wants to know if I want to recover the .lvproj.  I have been in communications with the manufacturer of the DIO part of the test system (not NI, I inherited the system) and they don't know anything about interfacing to LabVIEW, had the LabVIEW drivers (CIN wrappers) submitted by a user. In those I discovered that most of the .dll calls were using the stdcall method, with one (the handle close) using the C method. Also they all are marked to run in the UI thread. They weren't able to tell me if they were "thread safe" or not.

I did try setting them all to "C" calling convention, but it crashed immediately, with a much more informative message, basically "don't do that, wrong calling convention", but setting them all to "stdcall" hasn't apparently eliminated the crashes either. Had two in a fairly short period of time.

Anyone know of tools, Microsoft or otherwise, that might help me lay a trap for it?

Thanks,