Fatal Internal Error

[V_T_S]

Development Environment works fine, EXE is build successfully but, running the EXE display's the following error:

Any idea what is this?

[asbo]

There's not much to go on here. Does it appear that any of your code is executed before this happens? Add simple logging code to track how far the application gets before the crash occurs.

[V_T_S]

I agree there is not much information. There is no log because this error is displayed before the application initialize the Log.

BTW the EXE is a mix of LabVIEW and TestStand calls.

[hooovahh]

LabVIEW 10? Well there's your problem. LabVIEW does well every other release it seems. 7.0 - Not Good 7.1 - Great. 8.0 - Not good, 8.2 - Decent, 8.5 - Kinda Okay, 8.6 - Great, 2009 - Also Great (combo breaker), 2010 - Not so Good, 2011 - Good Again.

But on a serious note I would try to build in debug into the EXE. This makes the EXE much larger but you can run the EXE while performing basic probing on it like it was source.

I remember one time I had an EXE that has similar issues, I think it reported that it was broken as an EXE so I added debug to it and then it was no longer broken. It made the EXE larger but we didn't care at the time and was happy to see it working.

[jgcode]

I have seen that before - could be a bad VI?

I usually approach it by breaking down the exe - start building an exe using a component each time, until that error message pops up.

[V_T_S]

I have already gone thru the process of build the EXE using small components, and I also have debugging enabled.

I think trying the same build with LabVIEW 2011 seems to be a better approach.

[Aristos Queue]

There are two sources for this error. The most probable is a bug in LabVIEW of some sort. The less probable, but worth checking, is a Call Library Node in your own code that is calling a poorly written DLL or a poorly configured Call Library Node that doesn't match what the underlying DLL is doing. The memory manager can be messed up if a DLL modifies a piece of memory that LV did not expect it to modify.

If you aren't using DLL calls or if you already checked them for correctness, then it's probably an issue inside LV. The correct action at that point is to contact an NI Application Engineer (through the forums or by phone if you have a support contract) and see if they can debug what's going on. They can escalate a CAR and may be able to provide a workaround.

[Tomi Maila]

I have seen this error a few times when the application builder has not managed to successfully built a valid executable but hasn't returned an error either. Last time I saw this error was when there was not enough memory in the build machine for LabVIEW to build a proper executable. As a result the executable didn't really contain anything and the final size of the executable was too small. When executing it, you got this error, which was natural because the executable was corrupted. The problem really was in LV application builder. We fixed the issue first time by getting LabVIEW to address more memory in 32-bit machine during the build and the second time by moving the 32-bit LabVIEW used for building to 64-bit machine.

[V_T_S]

By getting LabVIEW to address more memory, the EXE is now working. Thanks Tomi

[Tomi Maila]

Would you like to report this to NI as a bug on application builder.

[labviewsolutions]

is a Call Library Node in your own code that is calling a poorly written DLL or a poorly configured Call Library Node that doesn't match what the underlying DLL is doing.

Yes, I also have seen this error before: The problem was that the VI uses a "Call Library Node" to call LabView itselfe and for some reasons it seems that the app builder uses the wrong LabVIEW File/Version to call (there where more than on versions of the LabVIEW runtimelib on the machine). Reinstalling LabVEIW fixes the problem for me.