LabView DAbort 0xF50EFD7B when closing LabView

[Agnea]

Hello everyone!

I have a weird problem with LabView and I was not able to find any solution elsewhere on the forum. 

LabView crashes with DAbort 0xF50EFD7B error in MemoryManager.cpp(1312) when I close the application after running the code. The log file indicates the main Vi from which all other subVis are called, but I'm assuming that it does so because I usually close the application from the main VI and that is when the crash happens. At the moment of the crash no code is running.

I do realize that it has to do with the memory but I have no idea why I see the error when no code is running. Could it have to do with version control software (I'm using git).

Grateful for any suggestions!

[Agnea]

Any ideas on this one?

[JÞB]

---

@Agnea wrote:

Any ideas on this one?

---

Perhaps we need more information.  In fact, even MY 8-Ball said "it is uncertain"  you really gave us nothing to work with

What is crashing?  The development environment or the runtime?

What version?

What OS?

One system only or can you duplicate it on a second machine?

Do you use appropriate error handling or are errors silently ignored?

How are you completing your code execution? Is there appropriate cleanup or do you use the Abort button?

What EXACTLY do the log file and crash report say?

What steps have you taken to isolate the cause? Disable structures around external calls can help find problems.

And of course,  post the code!

So, my best guess cannot be more specific than "No trouble! There is something wrong. Change the wrong thing to a right thing and your fine"

[rolfk]

And my favorite: Are you using any VI that uses a Call Library Node that is not from NI itself? If so, there is about a 99% change that this is the culprit. 

[Agnea]

Hi both!

Thank you for your answers!

More info: development environment is crashing (after code was run successfully to completion).

Version: LabView 20.0f1 (32-bit) on Windows 10, 64-bit

Tested it on two different machines, problem persists.

'Appropriate error handling' - not sure, I use error wires in every subVI and in the main VI

Completing code execution - it's a state machine, once all states and iterations are complete, it finishes with 'Stop' state which stops the while loop of the state machine

@rolfk Yes, I'm using dll's from suppliers, but I have been using them from the very beginning of the project, already before the problems started to appear.

Steps to isolate the cause: first, I cleaned-up the code, removed some subVIs which came from external suppliers. Next steps: disable data logging.

I've attached the log file after the crash. I will try to attach code soon, once I get access to the PC.

[rolfk]

---

@Agnea wrote:

@rolfk Yes, I'm using dll's from suppliers, but I have been using them from the very beginning of the project, already before the problems started to appear.

---

That's unfortunately nothing that would guarantee anything. Memory corruption bugs can go undetected for quite some time. Not every corruption is necessarily corrupting memory that contains pointers or memory offsets but it could also be data in your measurement arrays or similar. Those might go unnoticed for a long time until your quality department tells you one day that your measurements do not make much sense at all.

Then you make seemingly small changes to your application and the memory layout of allocated data structures changes and suddenly that corruption overwrites some not so vital pointer. Everything seems to keep working but when you try to terminate your application LabVIEW dutifully tries to deallocate all the memory it allocated throughout and then suddenly the memory manager bombs, indicating that one of the pointers it got handed over to deallocate simply points into neverland, rather than some valid memory area.

[JÞB]

Neverland! Lol. Second * to the left and straight on til morning