DAbort 0x89B93EF0

[joergv]

Hi colleagues!

Sorry for waking up this relatively old thread but this issue is one I have to deal with in my project every time I want to build an executable. My project is a pretty big one, containing 5613 vi's at the moment (still increasing). I had some excessive disussions with NI about that and finally we fond a solution which helps, at least for a while.

The solution is that before I build the executable I run a special vi which loads all project vi's (one after the other) and replaces all LV error controls with simple clusters of the same form. The difference is that the replacement clusters don't contain the 'red x' and 'green hook' images. So two images less for each replaced error control. Ths ables me to build the executable without this error. The lat time I built it, there were more than 10000 clusters replaced, which releaves the image table for more than 20000 entries.

I hope this may help the one or other of you.

Cheers, Joerg

Edit: The issue occurs regardless of the LV version. I tried 2011, 2014 and 2015.

[Hooovahh]

I haven't seen this issue so I can't say what would fix it, but I would not expect that replacing controls, with another control of the same data type, would do anything for a built EXE since almost all VIs have their front panels removed when built into an EXE.  The only VIs with their front panels left in an EXE are ones that are shown to the user, so unless you are showing all those 5000+ VIs as floating windows I'm not sure I can see why that would fix anything.  That being the case feel free to share this scripting code if you believe it will help.

[joergv]

You're right when you say that in the resulting executable only those frontpanels exist which are visible to the user.

But in the process of building the executable with application builder all project vi's will be loaded into memory completely, so including the frontpanel. If you have a project with more than 5000 vi's containing each error in and error out, there are pretty many error controls in memory.

Now, if you may take a deeper look at the error controls, you might become aware that the boolean control inside the error control is not a standared one but one with special icons, meaning the red X and the green hook. These images are held in the image table, one entry for each image of each error control. With a simple calculation you will come to the number of more than 20000 images ( >5000 vi's * 2 error controls/vi * 2 images/error control).

So replacing all error controls with standard clusters of the same type, but using a standard boolean without the special images, the image table will have about 20000 entries less than before. This enables the application builder to load all project vi's into memory without overfilling the image table. There is no effect to the resulting executable, all the error cases still work as expected.

I'm sorry that I have to say that the VI I'm using for this is not in a state that I want to show to anyone. I hope I will soon find the time to make it presentable, then I'd like to share it. I will post it here, when I'm done with that.

[Mac671]

Hi there,

I just wanted to get back here as I have seen your posts.

So even though the DAbort error and the hex numer are the same I think joergv that you are refering to a different problem.

My problem occured only @ runtime, when swapping between a tab control view that contained multiple intensity graphs.

The issue was present in LabVIEW 2014 f2 only and we initally worked arround it by reverting to 2014 f1 and eventually when SP1 came out for 2014 the issue no longer occured.

Your porblem seems to be happening even accros major LabVIEW releases.

Although Hoovah is right that the front panels will be carved out of your exe eventually, during the build process however All front panels are loaded. that is why complicated builds of LabVIEW projects which contain many VI's can be a royal pain in the ... neck. Anyhow I would think that there is some unfortunate corruption that happens here if you can share your code with NI folks to show them where this is happening this would probably be the best route to take, as it would be probably best for them to debug this issue to figure it out and fix it for all of us in the next patch for 2015!

Thank you,

Maciej