labview application crash

[RaymondFarmer]

I made a few small changes to my software, rebuilt and ran the application.

After a few hours of running, with the test VI being launched dynamically every 4 minutes, I suddenly received an Error 1059 at an Open VI Reference during. I dont know why it decided it wasn't going to open a reference to the VI this time round. The VI is contained in a Packed Library. It's closed on completion of its run, It had previously run probably several hundreds of time without any problems as indicated by the test result obtained and displayed. As it was an error the program came to a control termination.

The Error 1059, unexpected file type, was confusing. Nothing had changed with the packed library. The path to the VI in the packed library hadn't changed during the execution. The Caller VI is just the Open VI Reference, Call by reference and a Close Reference.

I read in the Help that the LabVIEW waits until the user interface is idle to load the VI from disk. So I added a 50ms Wait For and switched the execution of the VI to the "Interface I/O" setting instead of the "Same as Caller" which would have been the User Interface. I have had no further problem with error 1059 and have had two successfull ESS runs.

But unfortunately I haven't cured my crash problem. I had just started a run and the program was just doing some initial checks. It had just displayed a dialog to tell me my alignment files where out of date. I had the option to exit to main menu which was the option I took only It never made it to that option because the program crashed,

Loading VI Heap, HeapClass "FPHP", ............ - Dialog - Test Options.vi

This is not an unknown path through the software which hasn't been tested before, so I see no reason why it would crash. The Test Option.vi is a simple VI with a while loop, couple of buttons and an enum on the output connector pane. Nothing that would cause in to crash.

On the second attempt at running the application, I was able to run a full ESS run which ran over night and ran successfully  to completion.

I have started a duplcate project and stripped out a lot of the working code. I have removed all the dynamically called code from the project and now only shows those VI's it uses in the Dependencies.

I wanted to try recreate the crash seen before the Test Options.

I have created an exe and run this on the test system where I have been having the problems. At the moment no crashes, but I have noticed that then I close the application it closes almost immediately. Whereas my real application hangs around for several minutes before it fully closes. I have discovered what is causing this and it appears to be related to having NI_Report lvclass VIs in the main VI.

I have yet to tried removing the Print option from the real application an see if this cures my crash problem.

Another problem I have been having, when I build the execution and it reports that it's been successful. When I run the exe I get a dialog stating "This is an application template and cannot be run alone". I have to delete the build files, close the project close labVIEW, sometimes close the PC before I get a build that runs.

I have been informed that the company has nearly got a NDA with NI, so when that happens I be able to pass on some crash reports etc.

regards

Ray

[PK2015]

I have pretty much similar problem as you do. I do not know what would be solution for this. I hope they come up with something. 

[JakeA]

HI Ray,

Apologies for my belated reply, I was out of office for a couple of days. There are a number of things I've come across which account for some of the symptoms you've described. Is your executable quite large? If so, it could be that LabVIEW is running out of memory when building the executable. Something else to try would be a mass compile, which makes sure that all links to subVIs are correct: http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/mass_compiling_vis/. Finally, it could be that your Run Time Engine is corrupt and needs to be reinstalled. I don't think this is likely but I think it's a step worth taking to rule it out for sure.

You mentioned a NDA, do you know if you have a support contract with us? If you do have access to technical support then you can call or email us and send us your code so that we can deal with this issue far more quickly and smoothly.

_________________

PK2015, I would recommend that you make a separate thread as that sounds like quite a different issue. That way other forum members and other AEs can see the issue more easily and better help you to resolve it.

Regards,

[RaymondFarmer]

JakeA,

Going to see if the admin guys can reinstall the LabVIEW and Runtine Engine.

We are also seeing crashes when running in LabVIEW.

The last LVlog.txt quoted GencodeCallbacksRegistry.cpp and PatchLVRTRefs.cpp. Did a search and got a hit regarding PatchLVRTRefs.cpp in LabVIEW 2011 Bug Fixes (CAR ID 253700) but nothing regarding GencodeCallbacksRegistry.cpp.

The CAR ID 253700 suggest it was fixed in 2011 do you have anything regarding these.

Regards

Ray Farmer

[JakeA]

Reinstalling LabVIEW and the Runtime engine both sound like excellent steps to me. You can also try a force reinstall using the command prompt in order to reinstall every file and ensure that any issues with the installation are fixed, you can do that by following the instructions here: http://digital.ni.com/public.nsf/allkb/ADD22E807D5A12AD862579EC00760F79. I also had a look at that CAR and it could indeed be the source of the problem. You could confirm or refute this if you have access to a later version of LabVIEW on which to run this code, is this something you could do?

Regards,

[RaymondFarmer]

Hi JakeA,

I have since found out that the reinstall might not be a simple task at the moment, but the force reinstall might be a better option to try. Can you repost the link as its not working and I am getting an web error screen. So I would be interested in seeing the instructions.

I am also looking at what is happening with my dynamic calls to the packed library VIs occurs. I have change the one of my routines so that the packed library VIs are loaded into memory, then my test VI is run. When this runs the dynamic caller VI use the VI loaded in memory rather than load from file. At the end of the test run I close the packed library VIs.

Doing this has speeded up my tests but as yet I dont know if it has fixed the crashing. I have rebuilt the EXE and is now running the ESS routine. Even if hasn't I am going to leave it like this because the test time improvement is quite significant.

regards

Ray

[RaymondFarmer]

JakeA,

Not to worry about the link I managed to get it to work.

It was picking up the ". I" as well, so I deleted this and bingo the linked worked.

thanks

Ray