Fatal Internal Error MemoryManager.cpp

[Gert]

I've created a sequence file in teststand that uses the sub vi's for
reading out config files. If I run this on my development machine
there is no problem.

I tried to deloy everything onto a new target machine. I start to run
the sequence and i'm able to execute the 'Open Config Data.vi'. The
next step is to read out some data with the vi 'Read Key(String).vi'
but this creates the error. I get a Fatal Internal Error :
"MemoryManager.cpp" , line 406 LabVIEW 8.5.

What could cause this problem?

[griffindore]

Hi Gert,

The fatal internal error is a LabVIEW internal error. When you open LabVIEW, you should have the option to investigate the internal error. I suggest investigating the error. This will send an email with the error and error log to National Instruments. An engineer will then contact you for further information and work with you to find a workaround. Thanks and Happy Holidays!

[Rob_Calhoun]

I have been struggling with this error today. It appears that under some circumstances LabView does not automatically recompile all VIs requiring referencing a typedef when the typedef is changed. In my case, the problematic routine was one in which the typedef did not appear as a control, indicator or diagram constant. An array of the typedef was an output from one SubVI that was an input to another. The first routine had a case structure around it with some cases where the output took a default value. I assume the default typedef output is the core of the problem in my case. Manually recompiling the routine (or making any code changes to it) solved the problem.

One could probably do a mass recompile of the whole VI hierarchy to solve this problem, but that's undesirable in a large program that is being developed by a team. It is at least something to try if you are running into this error.

Unfortunately I have not been able to make a simple program that reproduces this problem. I have attached some code but it does not make LabView crash. However, bad pointer dereferences are tricky things to debug because the severity depends on where you end up when you dereference. (In my production code, LabView was trying to read location 0xFFFFFFFF; Windows killed it). So this example could be causing silent corruption. Or my suspicions could be ungrounded and the bug may lie elsewhere.

I do notice that when I change the typedef and quit labview, labview offers to save the TLVI and the two subVIs that contain the typedef control, but not the routine I suspect is causing the problem. ("Routine that doesn't recompile.vi" in my example.)

This message is related to support issue "Reference#7184406".

-Rob Calhoun

[Hillary_C_E]

Hi Rob,

Thanks for the details on your situation. I have passed these details on to the Applications Engineer working on your service request. This was reported to R&D (# 4E89TCK4) for further investigation.

[Sea Wind]

I faced the same error when I save the program compiled by LabView 2009 as a lower version (LabView 8.2). Once a window reminds such error, the labview will automatically shut down and does not restart. It may be caused by the use of event structure in the program. I am not sure.

I can not understand what you explain. Could you provide some possible solutions to avoid such error? 3x.