Corrupted VI causes Labview 6.1 to crash

[DAC324]

Hello all,
recently, I got a very sophisticated VI that should be used for data aquisition from a mass spectrometer, for adapting it accordingly.
Unfortunately, one of the subVIs included causes LABVIEW 6.1 to crash. I was able to track down the guilty VI but now I have no replacement for it. Is there a way to repair such corrupted VIs?

Thank you very much for any hint in advance,
Best regards

[asimpleman]

I had a corrupt vi once and it turned out to be a complex data structure that was corrupted. I had an array of clusters of many elements some of which were arrays. I was able to rebuild just that structure and it fixed the problem.

[Eric6756]

If your library of vis originates under LV4.x and you are now updating it to LV6.x, certain subroutine vis will crash LV6.x during conversion. I don't know that this is the case, but if it is, you need to make the vis asynchronous in LV4.x before attempting to update them. Hopefuly if this is the case, you have LV4.x, available...

Other than that, the only encountered I've had with this problem was vi that couldn't be loaded following a power outage. In that case, it was hopelessly lost.

If it isn't the first case, I'm not sure what to say except sorry, and hopefully someone else here or perhaps NI tech support might be able to help.

Eric

[JRA]

Eric's suggestion is a very good one. Make sure it was built in the same version. When I have had similar issues (multiple times), I always address them the same way and eventually find the source of the problem. Take your VI apart one piece at a time. For instance, remove one subVI and see if the rest works. If it does not, remove something else. Do this until you find which piece was causing the problem. Then, place a new one in.

For instance, I once found that the source of a corrupt VI was that a global variable was corrupt. I don't know why, but I simply replaced the global variable control with a new one and everything worked fine. I hope this helps you out.

[DAC324]

Thank you very much for your hints. Unfortunately, it can't be tracked down to only a program version issue since Labview 6i refuses to open that VI, too.
Since the VI file format seems to be a well-kept secret I had no idea where to tackle the problem. I found out that changing the byte at 00000011h let LabView open the VI, loading a lot of subVIs but then stopping asking for my first VI again. Entering the correct path into the open dialog had no effect.
In fact, the VI is named "Lei de controle CO2_MQR.vi" (my colleague is brazilian).
After opening the vi file Labview now loads some subVIs and then it stops asking me for "Lei de controle CO2_MQR.vi" again. Entering the correct path and filename has no effect, the program keeps asking for that file. At
first, I thought it may have something to do with the spaces in the filename but changing the name to a less complicated one had no success. Labview then keeps asking for that new filename.
Do you have any suggestions for solving this problem? Thank you very much in advance.

[Eric6756]

If you can find any vi, or better a control, that you can load without crashing LV and LV wants to save it when you close the front panel, it is almost certain that the vi/control was compiled under a previous version. I do not know if there is anyway to determine what version under which the original was saved. There is probably a header somewhere in the vi file that identifies this, but it is simply easier to try to load it with a previous version. If you don't have access to a previous LV version, knowing the version isn't going to help anyhow.

At this point, were it me, I would contact my colleague and ask him. I don't know that digging through the vi file structure is the most fruitful. I think it very likely the file structure is propr
ietary, and as I understand they are compressed, it will be difficult to determine what's what.

If for whatever reason your on your own with this, you can load the hierarchy without the vi by moving or deleting the vi from where LV expects to find it. Then when you load the top vi and LV asks for the missing vi, continue cancelling the dialog box until everything else is loaded. (In fact, if you have narrowed it to one vi, you probably have done this.) The diagram will still have the associated wires and connections and based on the wire descriptions perhaps you can find a control that is corrupted as indicated by others here.

If you still can't get it loaded, and you don't want to share the hirearchy, remove all the other vis from the library, if it is in a library, and upload it to tech support with a description of the problem and perhaps they can help.

If you can, I still think it would be most expedient to contact your colleage.

kind regards,
Eric

[Eric6756]

I was thinking about your problem, and it occured to me that the my advice is backward.

If you believe your crash is due to a corrupted control reference, global variable, or vi, you might try moving the the vi your trying to load to another location so that labVIEW has to search for all of the vi's external components/references. When you open the vi, and labVIEW asks you to find a missing file/reference, make a note of the file, and cancel the dialog. Eventually the vi should load without its external components. (If you can't get to this point, I think your kind of stuck.)

If you do get the vi opened, then open the missing files/references one by one. If or when LV crashes, repeat the procedure on that file/reference until you get to th
e root of the cause. You should be able to isolate the components or references that are causing the problem. (Actually, you may have already used this procedure to isolate the corrupted vi.)

As long as I'm here and the word hypocracy come to mind... If I remember right, I think the last revision to LV5 could open all my LV4 files whether they were subroutine vis or not. The LV4 subroutine vis that cause problems with earlier version of LV5 and LV6.0 are those that contain nodes changed from synchronous to asychronous execution, this includes, but may not be limited to, the Open Datalog File node as well as the Call Library Function node.

As I don't know all the nodes that may cause problems, if you have LV4 vis and your having problems converting them, try making all subroutine vis asynchronous in LV4 or with the last version of LV5 before trying to open them with LV6.0. LV6.1 is still an unknown to me.

Hope this is more helpful;

Kind Regards,
Eric