DAbort 0x26550A7E in transact.cpp

[Pflowers99]

Hello,

I'm still a bit new to labview so bear with me. I've only been working with it about 2 months. Today I was making some minor additions to a HUGE program I made in labview when everything went haywire. This morning I successfully added about 4 nested case structures with sub-VIs to make the minor improvements to the program but then it started to freeze up on me like the RAM was overloaded. I restart the program but it was still lagging. I restarted the PC but no better. LabView then started crashing...

I did file recovery on my program a few times and tried to keep working on it but when attempting to add any more sub-VIs it crashed giving me the following error:

DAbort 0x26550A7E in transact.cpp

Version: 12.0 (32-bit)

It stopped lagging after a few times of restarting the PC so the RAM overload is not the issue anymore. I then tried restarting the program several times and trying to edit it again but each time the program would crash as soon as I added ANY sub-VI to it. I wondered if the VI had been corrupted somehow.

I then restarted the computer then began getting the following DataFinder error during startup:

The DataFinder cannot start due to an internal error. (244): Please wait til the National Instruments PSP Service is running and try starting the DataFinder again, or reboot your computer.

I rebooted several times and kept getting that error 244 and Labview continued to crash when I tried to add any sub-VIs to my program.

I found this thread mentioning this sort of error: http://forums.ni.com/t5/LabVIEW/Error-244-The-DataFinder-cannot-start-due-to-an-internal-error/td-p/...

After following the instructions there I still could not get rid of the error. Ultimately, I just disabled DataFinder from msconfig and then proceeded to manually open DataFinder.exe myself after startup finished each time.

At this point I'm not really sure if the DataFinder startup error 244 and the crashing of Labview when I add sub-VIs to my program are related or not.

I'm running labview 12.0

windows xp

2.4GHz processor

2.5GB RAM

[Danubio]

Hello Pflowers99,

I've been researching more information regarding to your issue (DAbort 0x26550A7E at transact.cpp) and I've found that this is a very uncommon LabVIEW issue since 2011 version that  is currently being investigated. I would recommend you to first make the test with a simpler VI in order to check that there is no problem with adding that subVI to a more simple main program, also I would suggest you to try alternative ways to add the sub-VI to you Main code. You can drag it from your project, or press control+drag the subVI to the block diagram, or drag it from the desktop just to see how that works. Also you can try to run the program in a computer that have a later version of LabVIEW (like LabVIEW 2013 or 2013 SP1) and try to add the sub-VI un these versions in order to check if this problem was fixed for this later versions.

Best regards,

Daniel Cabezas

Applications Engineering

National Instruments

www.ni.com/support 

[Pflowers99]

Thank you for your response Danubio. I tried adding sub-VIs to a simple program. I have no problems doing this no matter how I add the sub-VI to the program. Upon trying your suggestion of adding the VIs in different ways, I then discovered that my big program only crashes if I add a sub-VI to it from the tools palette. If I use control+drag to add a new sub-VI it doesn't mind.

I also discovered that my big program only begins displaying this behavior once it gets to a specific size. That is to say, if I erase several of the most recently added sub-VIs and case structures I am able to add sub-VIs back to the program without it crashing. But it seems to always begin crashing once it has been built back up to a specific size (always the same point). It doesn't seem to be a problem with the specific sub-VIs I am trying to add at that point because I've tested adding them to other programs from the tools palette with no problems.

It is good that I have now found a way to continue working (using the control+drag method) but I wonder if this information gives you a clue as to the underlying issue. Is there possibly a more permanent solution that will allow me to use the tools palette directly on these big programs?

[Pflowers99]

By the way, I can't easily try another version of LabVIEW and it would be a real pain for me to upgrade on this system. Lots of hoops to jump through.

[Danubio]

Hi Pflowers99,

I'm glad to know that you are able to get back to work again. Regarding to how to get a better comprehension of why that behavior could be happening, I will suggest you to go in LabVIEW to tools » profile. There you will find some powerfull tools to analyze the execution of you VI before it gets to that piont when it crashes. Those are basically memory, performance and execution analysis tools. Try to use those with a code size that it doesn't crash to understand how are you using the PC resources, that should give you a good understaning of why this could be happening. You can also utilize the Windows tools like the task manager or the performance monitor in order to follow the trace of execution.

Best regards,

Daniel Cabezas

Applications Engineering

National Instruments

www.ni.com/support