Internal error (OMUDClassMutation.cpp) whenever I open my project

When opening my project (heavy on actor framework) I get the "Investigate Previous Error or Warning" dialog with the following error:
"The last time you ran LabVIEW, an internal warning, 0xEFBFD9AB occurred in OMUDClassMutation.cpp".
It seemed to be related to one of my actor message classes with "(not loaded)" showing next to it, however, after messing with that class (disconnecting from library and re-adding) it seems to have gotten rid of that problem. Still getting the above warning though when opening my project.
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

I run into this a lot also with LV2012. (Casually subscribing to this thread, curious to see the resolution.)
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Similar Messages

Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph

NOTE: This IS a duplicate post from the Breakpoint. Text slightly changed. The post in Breakpoint can be deleted. All comments should be placed in this thread.
I resolved the "Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph", but would like to share to find out if others have seen this and to determine whether this is a bug, or if it's time to redo my PC, or buy a new one..
I have an existing graphs (qt 6) which originally had 2 cursors. This occurred while trying to add the third cursor.
Up until attempting to add the last cursor, the program worked great, and I had been running tests for a while. However, I do recall seeing this problem when creating the original cursors, but not to this extent. Plus I don't remember the original error message from that time.
I needed to add one more cursor to the existing graphs. As soon as I add a new cursor and set it's properties, I get a nasty error message and without warning LV8.2 simply closes itself (well, the only warning was the error message. Tried it 3 times, same result.
Here are the steps:
Shut down the PC, went for a coffee, rebooted the PC. Opened the LV project, opened the VI. Immediately went to the graph properties to add the new cursor by doing the following steps:
Right click graph indicator icon on block diagram.
Select Properties.
Click on cursor tab.
Click on Add
Select Cursor 2 (3rd one, newly created)
Change color
Select cursor as a line
Remove checkmark for "show cursor"
Click OK
I need to do this to 3 other graphs, same steps. And as soon as I get to the step before clicking OK, I get the error message.
I managed to get an additional one done, by immediately saving after each step (yep going in & out of the properties). But I've had this problem before when creating the first two cursors.
Is it a bug? Anyone else seen this? Using LV8.2. And the message is right about LOOSING ALL unsaved work!!!!
Here are more observations:
Tried creating a new one on the second graph. As soon as I clicked on the color, it crashed!
See the error explanation below. It is really clear, now anyone can solve it    LOL!!... According to the error log, there's a bad image out there
.\manager\image.cpp(13192) : DAbort: bad image in ValidateImage
$Id: //labview/branches/Europa/dev/source/manager/image.cpp#47 $
0x007A81E8 - LabVIEW <unknown> + 0
0x007A7BDB - LabVIEW <unknown> + 0
0x00829D74 - LabVIEW <unknown> + 0
0x008546CD - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0081B9C8 - LabVIEW <unknown> + 0
0x0081EB9A - LabVIEW <unknown> + 0
0x0084D9D4 - LabVIEW <unknown> + 0
0x00854663 - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0085F7A1 - LabVIEW <unknown> + 0
0x00BBACDD - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
0x0085AA46 - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
I observed the title bar after making changes to the properties. I noticed that 3 out of 4 times, while changing the properties of the graphs to include the cursor, and saving after each & every step, that there were no stars appearing on the title bar to indicate "unsaved changes". Saving was also much slower than usual. I suspect, the program never got to placing the star before saving occurred. However, I am noting everything.
After creating the cursors, saving was and is normal, and the program runs well..   I have run tests without problems.
Does anyone have a clue at what causes this? Has anyone seen this before?
Thanks,
RayR

Hi Donovan,
I can't remember seeing this elsewhere. When I get a chance, I'll create a new (blank) vi with new graphs and will repeat the steps.
I will let you know if I see this in the new vi.
Thanks!
RayR

Internal error: "memory.cpp", line 593 with PXI 8175

Hi,
I have created a program with Labview RT 7.0 which makes acquisition, storage and display of data with PXI controllers 8175.
I used Datasocket for the data display on a deported computer.
Because of the number of the Datasocket tags used, instead of sending values all the time, I'm sending value for the deported computer only if the user needs to see it.
For example : if the user needs to see data, so only Datasocket tags for data display will be active, and if the user needs to see parameters values, so only parameters datasockets tags will be active. And, if the display program is in "standby" mode, almost all datasocket aren't active.
So when the user needs to see data values, he opens the data values window of the display program, and then, the datasockets tags for data value are now active, but : sometimes at this moment, the PXI stops with an "internal error "memory.cpp" line 593"!
The only solution is to manually reboot the PXI, the programmatically reboot doesn't work in this case of error. But it is far away from the displaying computer.
The error happens regularly after a 2 weeks period of standby. So I though about a memory overflow, I checked all the arrays, and none of them is growing to the infinity.
If someone knows about this problem, I will be very happy to learn about how to get rid of it!!!
Best Regards,
G Liagre
Best regards,
G Liagre

Hi Rob, Hi Matthieu,
Thank you for your reply.
I found in the database many reply about this error, but none of them were helpfull for me.
I tryed your link to the knowledge data base, but the error described there is for dll association in LabView and interface nodes.
I didn't used any interface node in my code.
The problem is that I cannot test my program on the PXI because I don't have access to it rightnow (only by remote desktop, and with a 56k modem..)
Let me give you a part of this huge code.
I suspect this part of the code to be the one which create the problem, but it's not sure.
If you find something obviously wrong, tell me!
Best regards,
G Liagre
Best regards,
G Liagre
Attachments:
Communication.zip ‏931 KB

Stop labview application from MS VC got internal error: image.cpp line 11450

Hi:
I need to control a labview application (It's been compiled as exe file)from my MS VC program. I tried using PostMessage(hWnd, WM_CLOSE) from whithin my program as MSDN suggested method to stop an application
cleanly. However, when i put my program in debugging mode and run it step by step, the LV program generate an internal error "image.cpp linexxxx" after it reached that PostMessage() call. in run mode , the Labview app simply ignore the WM_CLOSE message sent from my program.
So is there any other ways to stop labview application from VC program?
Thank you!
ls

> So is there any other ways to stop labview application from VC
> program?
You can use ActiveX. Turn the server on for your built app, open a
connection from VC, and use the app or VI properties to get LV to exit.
Greg McKaskle

Receive "Fatal Internal Error: Linker.cpp, line 1926 when run executable.

Hi, I use invoke node to call multiple subvi.vit, it work fine under .vi but when run under an executable I receive this error:
Fatal Internal Error: 'linker.cpp", line 1926
LabVIEW Version 7.0 You will lose any unsaved work. For more assistance in resolving this problem, please relaunch LabVIEW, or contact National Instruments.
Any suggestion will be very appreciated

Hi David,
What you are seeing is a known issue when calling LabVIEW 7.0 VITs from
an executable or DLL if the VITs include any Express VIs. It can happen if you
try to load
multiple instances of that template VI using VI Server.
There are a couple of workarounds for this issue:
Take
all the express VIs that are inside the template VI and turn them into
static subVIs. You can do this by right-clicking on the express VI and
selecting "Open Front Panel"; then save the express VI as a normal
subVI.
Build the entire application into a single executable, which will force all of the express VIs to get compiled as static subVIs.
Don't use the runtime engine at all and always run your application in development mode.
Let me know if the workarounds fix your issue, thanks.
Good luck!
- Philip Courtois, Thinkbot Solutions

Can somebody fix my corrupted subvi, error "Fatal Internal Error" "objheap.cpp"

Hello,
I have been strugling to open this file after a reboot due to not responding computer. The file is a part a larger library however, this is the part that is not responding and giving "Fatal Internal Error" "objheap.cpp" .
Does anyone know how to fix this issue or how to repair this file.
I am using a LabView 2012.
Thank you for your time.
Attachments:
Corrupted.llb ‏149 KB

Hi obarriel,
that could be a tricky job as LV2013 claims "block diagram can't be opened"!
Meanwhile you should learn two things:
- using LLBs isn't recommend practice nowadays (atleast not for storing daily work VIs)
- make a backup of your works on a regular basis (using SVN/GIT is recommended too…)
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Fatal Internal Error MemoryManager.cpp

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?

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
Attachments:
MemoryManagerCrash.zip ‏36 KB

Fatal Internal error: "oleautomgr.cpp", line 2832

Hi,
I have a program developped with LV 8.2.1.
Now I have import this application with LV 8.5; if I run the VIs in Labview it works; when I run my program (executable version) I got this error
"Fatal Internal error: "oleautomgr.cpp", line 2832"
I got the error after I open a Diadem connection.
Another information: first time I have import the program in LV 8.5 and I have save the prj, LV ask me to overwrite all the VIs of the "Diadem addons". (Diadem connectivity); so I have uncheck "read only" in Diadem.llb and I have save the Vi.
Someone can help me?
Thanx a lot

For the community's future reference, this issue was resolved by the customer calling in for support, at which time it was determined that a Mass Compile of the VIs was necessary to eliminate the error. The process to mass compile is described here.
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

I have encountered the new error "Fatal internal error fpinit.cpp line 7398

I get the error message "Fatal internal error fpinit.cpp line 7398".
I use:
TestStand 2.0
LabView 7.1
Vision 7.1
uEye USb Camera
I've included into my TestStand programm some new steps that control the uEye USB Camera.
I use following steps (all steps written in LabView):
- Initialze Camera
- Wait
- Close Camera
- Wait
I have the settings "Load dynamically" in TestStand"
If I use also the setting "Unload after sequence executes" and start the sequence I get somtimes a LabView error after running the Step for the Camera initialization. LabView is sometimes immediatlly closed. This happen at leased after 10 turns/starts of the programm. If I use the loop functions "Loop on selected steps" it happen only sometimes at the first loop. The initialize Camera Step is every time pass, if TestStand try to run the next step I get a error.( Sometimes I get also the message ActiveX Server got lost)
I detected also that sometimes in this case a constant in a other vi is emty.
Normally I use the setting "Unload when sequence file is closed" then I have the problem only sometimes at the first turn.
If the initialize Camera step is succesfull I have no problem with further camera steps.
Regards
Alexander
Attachments:
lvlog02-18-10-09-34-10.txt ‏1 KB
Copy of Error.jpg ‏76 KB
Copy of Error2.jpg ‏42 KB

Hi Alex,
I'd suggest to replace all ctl. with new ones.
Perhaps one of them is corrupt.
You will find a documentation about preferred execution system
in the LabVIEW help. I also attached this files.
Regards
DianaS
Attachments:
help1.gif ‏37 KB
help2.gif ‏11 KB

Fatal Internal Error : "OMUDClassMgr.cpp". Line 1128

I received the following message:
Fatal Internal Error : "OMUDClassMgr.cpp", 1128
LabVIEW version 8.2.1
I was trying to build an application using the application builder.
Has anyone else had this issue? What needs to be done to fix this.

Hello,
This was reported to R&D (#4ALB7O89) for further investigation. Are you able to reproduce this problem with the same VI? Are you able to build an application with a simple VI?
Regards,
Elizabeth S.
Applications Engineer
National Instruments

Internal Error (safepoint.cpp:261)

Hi,
We have embedded Java to our software through JNI. We did upgrade to our Java version to 1.6.0_06 recently, one reason we did this was that 1.4.2 wouldn't start on Linux (Red Hat Enterprise Linux ES release 3) environments. Now, 1.6.0_06 starts ok, and usually runs for 5-6 hours and then crashes with error that is beyond our knowledge. We've had this problem with several of our customers so if anyone could give us a hint what to do with it?
The error we get keeps pointing to safepoint.cpp line 261.
Here's the error log, I couldn't attach full log because of message size limit, but let me know if you need anything else:
# An unexpected error has been detected by Java Runtime Environment:
# Internal Error (safepoint.cpp:261), pid=13063, tid=13589424
# Error: guarantee(PageArmed == 0,"invariant")
# Java VM: Java HotSpot(TM) Client VM (10.0-b22 mixed mode, sharing linux-x86)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
--------------- T H R E A D ---------------
Current thread (0xb74fe000): VMThread [stack: 0x00c75000,0x00cf6000] [id=13075]
Stack: [0x00c75000,0x00cf6000], sp=0x00cf54c0, free space=513k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x3bdb69]
V [libjvm.so+0x1c002f]
V [libjvm.so+0x3436d9]
V [libjvm.so+0x3cb283]
V [libjvm.so+0x3cae6f]
V [libjvm.so+0x3113f9]
C [libpthread.so.0+0x4dd8]
VM_Operation (0x00487360): RevokeBias, mode: safepoint, requested by thread 0xb7500800
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux ES release 3 (Taroon Update 8)
uname:Linux 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:38:41 EDT 2006 i686
libc:glibc 2.3.2 NPTL 0.60
rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
load average:1.24 1.42 1.10
CPU:total 2 (1 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 2055464k(23988k free), swap 3148700k(3120236k free)
vm_info: Java HotSpot(TM) Client VM (10.0-b22) for linux-x86 JRE (1.6.0_06-b02), built on Mar 25 2008 00:39:19 by "java_re" with gcc 3.2.1-7a (J2SE release)
time: Mon Dec 8 10:05:48 2008
elapsed time: 16411 seconds
Best Regards,
Janne

rotoflex wrote:
Different enviroments may just be the case but even then it shouldn't crash like this? Yes it will.
As I said a pointer problem can show up in different ways based on execution. And a different enviroment means a different execution path.
What I'd like to know is what is the thing that causes this crash and how we can avoid it, even if it means altering our JNI code.
Find the pointer bugs.
Fix the pointer bugs.
Our software uses dynamic linking and libjvm.so from Java6 is loaded runtime. What I meant was we're using jni_version 1.2 option while compiling.Ok.
Keep in mind that I said such probably are usually JNI related. Some other possibilities
1. You are using a third party library (called from your C code) incorrectly. That indirectly causes pointer problems.
2. Bug in the third party library.
3. Environent problems. Some software is corrupted. Hardware failure. This is less likely on multiple systems but it can exhibit itself your install process is installing multiple components (like OS patches) and you are missing something.
4. Something is wrong with the VM.
Despite the possibility that it could be cause by something else the most likely possibility is still your own code (note that in 1 above that would still be a problem with your code.)

Fatal Internal Error : "LinkObj.cpp

Hi,
I currently upgraded the system from labview 8.0 to labview 8.0.1 and did a mass complile.
However after doing that I am getting an error message reading "Fatal Internal Error : "LinkObj.cpp", line 587" everytime I close a particular sequence in TestStand. This error never used to occur before the update.
The error seems to occur when it tries to unload a particular VI which I use to add tasks in MAX.
I have tried repairing Labview but the problem still exists.
I would appreciate any help
Kewal
Attachments:
error message.JPG ‏15 KB

OK, now it's getting comical...
I removed the second mathscript node from clasclap.vi and created a dummy LV math operation to replace it. Called the new vi clasclap_part.vi (attached) and added it to the project in place of clasclap.vi. Built the dll as usual. BTW, I'm using the standard calling convention here, not the C language convention.
RESULTS: All of the called functions return zeros, even clasclap_part.vi. But some good news: the dll isn't crashing Visual Studio anymore.
Now I'm realizing that the functions returning zeros issue greatly overshadows the reason I originally started this thread. If I don't get any response, I'll start an independent thread that someone might take an interest in....
What might be helpful here would be if someone could (hopefully easily) take the summer .vis and the clasclap_part.vi and build their own dll. Then, try to call it from VB6 and/or any other language or compiler. What do you get?
(FWIW, I never mentioned that I'm not a fan of VB or Visual Studio. LabVIEW is far superior IMHO)
Here is the revised VB code which calls the dll:
Private Declare Function Summer Lib "summerlib" (ByVal a As Long, ByVal b As Long) As Long
Private Declare Function Mathscriptsummer Lib "summerlib" (ByVal a As Long, ByVal b As Long) As Long
Private Declare Function Doublesummer Lib "summerlib" (ByVal x As Double, ByVal y As Double) As Double
Private Declare Function Clasclap_part Lib "summerlib" (ByVal x As Double) As Double
Sub Form_Load()
Dim x, y, fx As Double
Dim a, b, sum As Long
a = 1#
b = 2#
x = 1.2345
y = 2.3456
fx = 1
sum = Summer(a, b)
fx = Doublesummer(x, y)
sum = Mathscriptsummer(a, b)
y = Clasclap_part(290.01)
End Sub
Thanks,
Ted
Attachments:
clasclap_part.vi ‏276 KB

"Fatal internal error:"memory.cpp",line 593"

I need some help.
Can some please explain what i am doing wrong here. i have created a Dll from a LV 7.0 vi. The header file looks something like this:
typedef struct {
long dimSize;
double elt[1];
} TD2;
typedef TD2 **TD2Hdl;
typedef struct {
double f0;
double df;
TD2Hdl magnitude;
} TD1;
void __cdecl Spectrum(double freq, double amp, TD1 *Spec);
And i have the following code where i allocate memory and attempt to call 'Spectrum':-
TD1 *Power;
double frequency=10, amplitude=1;
Power = (TD1 *) malloc(sizeof(TD1));
(*Power).magnitude = (TD2**)malloc(sizeof(TD2));
*(*Power).magnitude = (TD2*)malloc(5000*sizeof(TD2));
(*Power->magnitude)->dimSize = 5000;
for (i=0; i<500;
i++) {
(*Power->magnitude)->elt[i] = 0;
Spectrum(frequency, amplitude, Power);
I keep getting Fatal internal error: "memory.cpp", line 593" when it tries to call Spectrum. I believe i have allocated memory correctly although i may be wrong. (I was getting 'exception' errors before). The VI i used to create the Dll contains a basic 'Function Generator' (sine wave) and a 'Power Spectrum'.
I have looked at the Knowledge base and dll examples that come with LV 7.0 and have tried setCINArray and NumericArrayResize but have not had any luck. It seems like the documentation is for LV 6.0 and 6.1.
Has anybody seen this or have any idea why i am getting this?
Thanks

> Can some please explain what i am doing wrong here. i have created a
> Dll from a LV 7.0 vi. The header file looks something like this:
>
> double frequency=10, amplitude=1;
> Power = (TD1 *) malloc(sizeof(TD1));
> (*Power).magnitude = (TD2**)malloc(sizeof(TD2));
> *(*Power).magnitude = (TD2*)malloc(5000*sizeof(TD2));
>
> (*Power->magnitude)->dimSize = 5000;
>
> for (i=0; i<500; i++) {
> (*Power->magnitude)->elt[i] = 0;
> }
>
> Spectrum(frequency, amplitude, Power);
>
> I keep getting Fatal internal error: "memory.cpp", line 593" when it
> tries to call Spectrum. I believe i have allocated memory correctly
> although i may be wrong. (I was getting 'exception' errors before).
> The VI i used to create the Dll contains a basic
'Function Generator'
> (sine wave) and a 'Power Spectrum'.
> I have looked at the Knowledge base and dll examples that come with LV
> 7.0 and have tried setCINArray and NumericArrayResize but have not had
> any luck. It seems like the documentation is for LV 6.0 and 6.1.
>
It looks to me like you are constructing arrays to pass to LV using
malloc, instead of the labview.lib functions for creating or resizing LV
array handles.
You should refer to the manual on Calling External code for details on
the construction of an array.
Greg McKaskle

Upgrade 3.1- 7.0: internal error Workbook storage fault (read/open)

Dear all,
after upgrading an 3.1 (SP12) BW-system to BI 7.0 (SP15) the following error occures when we want to open existing BEx workbooks (in the BEx Analyzer 3.x):
<b><internal error> Workbook storage fault (read/open)</b>
<b>We have found out, that this refers only to those BW workbooks being created in BW 2.x and not modified ever since. Thus this actually seems to be an 2.x->7.0 issue.</b>
Scope of our projekt it not the use of any new BI function, we are just upgrading the system.
Unfortunately some (but not all) workbooks do not run any more now. Checking existing SAPnotes has not helped yet unfortunately.
I saw very similar problems on this forum, if there is a solution, please provide it to us urgently.
THANKS for helping
Frank

Hello Venkat,
thanks for helping. Since I work with SAP_ALL authorization, I do not think this issue is related to missing auth. objects. The error message desribed above is withoutan number-ID, that´s why it is different than those described in the mentioned notes.
It definitely is related with the upgrade, as I can open those "corrupt" workbooks originating from BW 2.x in the productive system (still on BW3.1).
Any more suggestions?? Who remembers the 2.x - 3.x upgrade of BEx workbooks?
Thanks, Frank
null

Fatal Internal error: "oleautomgr.cpp", line 2832 when sending data by means of ActiveX methode

I have experienced error "Fatal Internal error: "oleautomgr.cpp", line 2832" during sending data to CAN card IXXAT iPCI-I XC16/PCI. LabVIEW communicates with that card by means of ActiveX methodes via "VCI Wrapper" which is COM object interface. Mass compiling of the project does not help. Card is initialized and configured propely. The driver card is working propely.
LabVIEW version is 8.5
The efect of that error is that labview completly shot down.
I appraciate any suggetions
thanks a lot

Hello,
Please try to reinstall the drivers for the CAN card, then make sure you close all references to the ActiveX control (at all levels) using the Automation Close primitive in LabVIEW.
Regards,
Emil

Internal error (OMUDClassMutation.cpp) whenever I open my project

Similar Messages

Maybe you are looking for