internal warning 0x occurred in MemoryManager.cpp

[X___]

Anyone has had to deal with this type of warning and know how to handle them?

I have communicated the associated report several times but have now given up as I am sure NI does have better things to do (say bug fixes).

LV 2019 SP1 64-bit on Windows 10.

[X___]

Appropriately enough, I recently got this startup warning as well:

The last time you ran LabVIEW, internal warning 0x occurred in xstuffprivate.cpp.

 

[X___]

The last time you ran LabVIEW, internal warning 0x occurred in image.cpp.

[Rolf Kalbermatter]

You either have a considerably corrupted LabVIEW installation or are executing some external code (through Call Library Node or possibly even as ActiveX or .Net component) that is not behaving properly and corrupts memory! At least for the Call Library Node it could be also an incorrect configuration of the Call Library Node that causes this.

Good luck hunting for this. The best way if you have no suspicion about possible corrupting candidates is to "divide and conquer". Start to exclude part of your application from executing and then run it for some time and see if those errors disappear. Once you found a code part that seems to be the culprit, go and disable smaller parts of that code and test again. It ain't easy but you have to start somewhere. Just because your program doesn't crash right away when executing (or the test VIs that come with such an external code library) does not provide any guarantee that it is fully correct and not corrupting memory anyhow. Not every corruption leads immediately to a crash. Some may just cause slight (or not so sligh) artefacts in measurement data, some may corrupt memory that is later accessed (sometimes as late as when you try to close your VIs or shutdown LabVIEW and LabVIEW dutifully wants to clean all resources, and then stumbles over corrupted pointers, and only when serious things like stack corruption happen do you usually get an immediate crash.

Edited March 1, 2021 by Rolf Kalbermatter

[X___]

I have my suspicions. But I like the terseness of the warnings (which pop-up only upon restarting LabVIEW).

I suppose there is not more info that can be provided to the user (the LVInternalReports are binary files, so I can't make much of them).

[dadreamer]

2 hours ago, X___ said:

I suppose there is not more info that can be provided to the user (the LVInternalReports are binary files, so I can't make much of them).

Maybe you could figure out more information, when you add these lines to your labview.ini:

Quote

createLogFile=True
DPrintfLogging=True
DPrintfToFile=True
promoteDWarnInternals=True

You need to restart LabVIEW after that. When started, it will create DPrintf text file near labview.exe with a tons of a technical information. That info is often very low-level and internal to LabVIEW development, so it may be difficult to analyze. But it's something at least.

[X___]

Sounds good. Will try.

[X___]

<DEBUG_OUTPUT>
3/12/2021 10:42:37.511 AM
DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)]
e:\builds\penguin\labview\branches\2019\dev\source\compiler\compiler.cpp(621) : DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)]
$Id: //labview/branches/2019/dev/source/compiler/compiler.cpp#6 $

 

First comment: the penguin has reared its ugly head (or tail) again! I do not have a E: drive on my PC, so this is probably some internal stuff, as is the //labview/branches/... thing.

The ix.vim is mine though and while not doing what I want, it looks pretty innocuous:

[andy_r]

@X___ you had any progress on that more detailed error message? I recently had a similar message with a different VI of mine. But I have no clue why this VI could cause this, meaning it looks pretty innocuous to me as well.

[X___]

I followed @dadreamer's advice and now get verbose logs every time I get this. There are a few Insane object warnings I need to investigate in my main VI (some cluster constants), and some bizarre DSDisposeHandle errors pointing to that non-existing penguin path, a load of messages regarding references that couldn't be found in a cookie jar, some "this is dangerous" warnings, and tons of weird internal self-addressed warnings...

I may contact NI support at some point, but since it is not killing me, I have put that on the "to do" pile.