LabVIEW Class crash - ntdll.dll access violation

[GoofyWires]

Hi,

When I close my LV11SP1f2 I always get a warning.

It didn't bother me until a vi I wrote that uses a class with nothing out of the ordinary started crashing my LV.

The crash says that: "DAbort 0x37C03D in MemoryManager.cpp"

I sent the log files to the local support and they saw that the common issue between my logs is an access violation in ntdll.dll.

Any operation that uses the property nodes of that crazy class fails, sometimes with a crash and sometimes with a error that sends me to a bundle by name in the autocreated property node.

I rewrote the project with the class and there is no error.

Sending the crashing project to another computer gave no error.

Before I go on and investigate windbg to search for a conflicting app and finally formatting my entire computer could some1 help? Please...

I attached several logs for example.

Thanks in advance,

GoofyWires.

[Edna-S]

Hi GoofyWires,

So do you get the MemoryManager.cpp error only with this VI or with all of your LabVIEW VIs? If so maybe unistall/reinstall your LabVIEW would be a good idea. Are you using OOP(object oriented programming) in LabVIEW? if so then using property nodes to change the parameters of a class could be the problem for crashing your VI. Because you are trying to edit what is already in the memory. Did you meant to include your VI in the attached zip files? Can you send in your VI, or a screen shot of it?

[GoofyWires]

Hi Edna,

I'm using LVOOP. Regular vis doesn't normally crash.

Even LVOOP vis doesn't crash normally.

However, each vi that uses a property node of this particular class crashes.

It is not a coding mistake since I rewrote that class and vi and everything works great.

Moreover, this crashing class and vi works great on other computers.

As for the warning that I get when I close LV, it happens all the time.

I don't know if that is related but the first time I right click a BD element takes about 10 seconds before I window shows.

I posted here in order to avoid reinstalling LabVIEW which takes more than a day with all the extensions.

As for you saying that using property nodes that a class provides are the cause for the total LV crash, that sounds like a complete nonsense.

I use it all the time with no problem, many examples are using it and so on!

I attached 2 zip files, the one called ASCII Bad crashes my LV while the Test Project doesn't even though there are no differences between them.

I also attached a test file that you'll need to run the examples (and change the hardcoded path inside (sorry, I'm not next to LV to do the changes).

Thanks in advance,

GW.

P.S. - if you don't have the same LV issue/instability as I do I guess both projects will run smoothly for you.

I guess this is actually a conflict with another program either inside LV or outside that only a LabVIEW expert could solve and help me avoid a complete format of my PC.

[Edna-S]

I was able to run both of the VIs successfully on my PC. I replaced the Do.vi with some random constants for testing. So it looks like your software has been installed incorrectly or some files are missing. I would suggest you repaire LabVIEW first and that hopefully that will fix the problem.

[GoofyWires]

Hi Edna,

Obviously I can try uninstalling and even formating the pc, however, the point of me posting here is to find a way to avoid this crazy step.

If this is a sowftware conflict uninstalling won't even help.

Thus, I would like to know if there is any information in the logs that can dirrect me to the problem and if not I would like to know if I can check some advanced information maybe inside the Heap Peak.

I never used WinDbg or the Heap Peak yet with some instructions I think I'll be able to handle both.

A LV support expert remote logging into my pc checking those option would be even better since I don't have even hours to spend on it.

Thanks in advance,

GF.

P.S. - The warning when I close LV indicate some instability yet the specific bug with the class is not a repeatable problem. For the warning alone I'm not going to uninstall LV. As for this particular class, I manipulated the class cluster and property nodes many times and creating the property nodes froze LV several times if I had, by mistake, left two identical fields in the class control cluster.

The fact that LV can't handle fields with special characters, a label with two lines and duplicate feilds is, I think, a very big bug that should be handled ASAP.

[Edna-S]

Can you try to generate a MAX report by following the link below? Then you can either compare it with a computer that runs your projects with no error, or you can send it to us, and we can compare it for you. Just to make sure you have all necessary items installed on your computer. Meanwhile you can try reparing your LabVIEW, this is different from uninstalling. It will just look and see what is missing in your PC, and adds it. So it shouldn't take you long time to do this!

http://digital.ni.com/public.nsf/allkb/271F252B4EF0A2E0862570E70056A1E4?OpenDocument

[GoofyWires]

I did a clean format and reinstalled LabVIEW 11.0.1f2 without adding many of the add-ons from VIPM and without installing the rest of my shortwave, yet, the crash is still here!

I was able to reproduce it on my pc:

1. I have a class that contains two children of another class which each contain another class with a class inside it.

2. I accessed the classed through property nodes.

3. I then went on and deleted a private data from the first class control, deleted its property nodes and added a new private data to that class control and added the property nodes for it.

4. I updated the vi that used the classes to stop using the deprecated property node and start working with the new one.

5. I did a "save all" and run the vi. All OK!

6. I closed LabVIEW and reopened the project and run the vi which is not broken! LabVIEW crashes!!!

I guess the complexity of the class is not the issue and it can be reproduced in a much simpler way.

Yet, since I bet the scenario caused you to raise an eye brow I'll give an example as an analogy:

File Handler class contains ASCII Read class and ASCII Write class which inherit from class ASCII.

Class ASCII parent contains class Headers while class Header contains class Data.

Thus, class ASCII Handler will use class ASCII Read/Write to give a high level simple interface while during the read/write the inner ASCII Read, for example, will add to the Header class in it the read data which will in turn be added to the array in the private data of class Data.

I'll try and reproduce it on a different pc and send the local NI support the code and way to reproduce.

I see two possibilities:

1. Something is wrong with my new Dell PC.

2. LabVIEW doesn't handle and propagate correctly changes in a class to all the vis that use it. Maybe changing the array size in a class overrides some memory since the class can't change its size.

Please let me know if this rings a bell.

Update: I coundn't reproduce the crash on my pc with a simpler case. There is something missing...

I'll try to replroduce with the complex class on a different pc and if it crashes I'll simply send my original code.

[OlivierL]

Was there ever a resolution to this issue or any more details to share about it?  We are also currenlty facing error "DAbort 0x37C03D in MemoryManager.cpp" and we have little information as to the root cause of the issue.  Using LV2011 as well.

[GoofyWires]

Move to LV2013 with the same code or rename the class names and change them back again with each change.

LV2011 classes crash if you sneeze (take a look at the known bugs list).

If LV had implemented OO correctly from the start I could have earned twice as much by now yet instead I had a year and a half of failed projects that gave me a bad reputation.

Actually, I keep having failed projects or projects that don't end on time and had to be redesigned because of and around LV bugs.

The fact that you have the same problem makes me feel as if I'm not alone debugging LV for free.