Fatal Internal Error 0xF50EFD7B: MemoryManager.cpp, line 1187

[chembo]

This message popped up after the code was running already 2 days. I noticed it one day later (after the error) and most of the code was still running in background. i.e. error log, event log, some other logs, etc...

Everything disappeared after I clicked the OK button. There are no LabVIEW failure logs at all, no Windows Event Logs either. The LabVIEW program runs as .Net DLL and this is the first time ever I see this error (LabVIEW 2014, 64-bit, on Windows 7 64-bit)

I couldn't find anything online. Did anyone see this error already? Any info about it?

[pincpanter]

Did you check the memory usage of your application over time?

It's also possible that some piece of code kept messing up mildly with the process memory until it crashed (wrong memory allocation on function calls).

Yet it's peculiar that some other parts of program are still running.

[chembo]

Yes, the software is logging the memory every second (physical and virtual). This log was still running: no peaks at all and there is constantly almost 8GB memory available.  

[jdel12]

Hi chembo! Would you mind explaining your code? Do you open too many references? You could try using the Desktop Execution Trace Toolkit to see which VI makes the MemoryManager.cpp give that error.

[chembo]

We have a third party application which calls our code, something like main user interface. But most of the user interfaces are provided by our LabVIEW code. It runs as .NET DLL and it is pretty big (8K to 10K Vis).

Unfortunately DETT cannot trace DLLs. I was trying to use it before in order to troubleshoot some other problems and it didn't work. Then, I am pretty sure, I checked with NI support and was told that it doesn't work with DLLs. 

I mentioned already before, that most of the code was still working, because it was still logging. Just one specific log disappeared. We didn't make any recent changes in this part of the code.

The program is very stable and runs since long time in production, sometimes weeks without restart. We see this error for a very first time. Fortunately this was on one of our test systems. I am just trying to find more info about that. One of the problems is that there was no LabVIEW failure log at all. Usually we can find a log after LabVIEW crash, but this time there is nothing. Not even a Windows event log entry.

[jdel12]

Ok, then I guess you can't reproduce the error and it would be hard to narrow the source of the issue, since it can run without restarting and it is kind of an isolated case.

After searching in Google I found this KB (a little old, but may be helpful): http://digital.ni.com/public.nsf/allkb/01B186B5CEB1D07786256747000F4319 It has some steps for troubleshooting this errors. One of them is mass compile the VIs, I don't know if you have tried that already. Another thing to do is check if the DLLs are thread safe, because it may have happened that two parts of the code tried to acces the same thread or the same information and that's where it crashed. 

There might be other reasons but maybe you could try that and see if it works.

[chembo]

Thanks, I will check it out and update the case if I figure out the source of the error

[3d0g]

Just curious. Did you ever figure it out, chembo?  ...the mystery line 1187...  

[3d0g]

Incidentally, I can reproduce the error, over and over.  It happens when returning from what's believed to be correctly functioning code, for the code works just fine as an executable.  LabVIEW calls it, however, and then gets lost on its way back from "return 0;"   In other words, what I'm saying is the code itself works -- I know it works because I'm dumping non-trivial information to the console, throughout -- it's LabVIEW that gets lost returning from it, dying in this "I died in line 1187" message.

I too have been searching and searching and searching for 1) explanation of MemoryManager.cpp from NI, and 2) what MemoryManager.cpp says in line 1187.  Whatever it's saying my code kills it, over and over and over again, dependably.  (Why?  I keep running it expecting I'll have a catastrophic meltdown of some sort, eventually.  One can only destroy memory for so long.  Blue screen. Black screen.  Something.  Lockup.  But so far, nope.  My code runs and then LabVIEW just dies, over and over.  Run, rinse, and repeat.  I think LabVIEW's broken.)

[3d0g]

Isn't that the way it goes?  Ask the experts out there and before you get a response you resolve the issue.  Well here's to the others who stumble into this thread and the mysterious line 1187.

MemoryManager.cpp cannot handle, at least, a complicated pointer parameter sent to a CLFN.  Rather, determine how many bytes of memory you're going to need and then just build an array of that size or more and then point to the array when you call CLFN (pointer to array.)  I was trying to get MemoryManager.cpp to understand an array of structs, where each struct consisted of 4 uint32's, 2 strings, and a pointer.  Go figure my dll worked fine but then MemoryManager.cpp croaked on the way back.  I went to a simple array of appropriate size and had no issue with the return to LabVIEW.  Of course you'll have to do as I and parse it all, later, with whatever crazy boundaries and C-strings, but at least it works, now.  I just figured I'd give back to all of you out there who have helped me.