SubVI missing, but visible in windows

[Casey]

It looks like one of my sub-VIs has gotten corrupted (for a 2nd time).  The main VI will load, but it pops a dialog box asking for the location of the one, sub-VI.  The sub-VI is there, and clicking on it gets the same dialog box back.  Even if I just try to open the sub-VI, I get a dialog asking to locate that same sib-VI.  I'm using Labview 7.1 running on XP, and the last time the sub-VI was not corrupt is was programatically closed using VI server.

I'm not sure how the routine got corrupted, and I have no idea how to bring it back.  The last time I reverted back to an old saved copy (lost several hours of work) and made my changes again.  Any advice, aside from save more often?

Thanks,

Casey

[smercurio_fc]

Are you sure it's not your hard drive that's causing the corruption in terms of bad sectors? I've never heard of the VI Server corrupting VIs. How have you established that it is corrupt? Can you open the VI directly from disk by itself? If so, what happens when you open the subVI first and then open the main VI?

[Casey]

This is the 2nd time this has happened, both to the same VI, and in a different fold each time.  The behavior is that Labview can't open the file, even though Windows sees it.

If I try to open the file in Labview, either just by opening the file itself, or by opening a VI that calls the corrupt VI, Labview spawns a dialog box asking for the location of the corrupt file.  It's right there in the directory, with the proper file name, and if I click on it, I just get the same dialog again, which again asks for the same file which is properly named and in the directory.  This is an infinite loop.

If I go into windows, the file looks fine.  It's size, properties, date all look fine.  However, Labview just won't open it.

Because it's happened twice, both times to the same VI, but in different directories (I'm saving very often now), I really do not suspect the hard disk.  Aside from this behavior with this particular file, the rest of my system is running normally.

Do you know of any way to "debug" a VI that won't open?  Reverting to saved copies is really not the way to go.

[tbob]

Does the file name contain blank spaces before or after the entire name?  Does it contain unprintable characters?  I suspect that labview is looking for a filename with some extra unprintable character somewhere in the name, and windows displays the filename without the unprintable character.  Rename the subvi to something else.  Then when you open the main vi and it asks for the subvi, just click ignore.  Then in the main vi block diagram, you will see a box with a question mark where the subvi once was.  Delete the question mark and replace with the newly renamed subvi.  You will have to do this at every location the subvi appears.

[Casey]

The subVI's name hasn't changed.  It's got the same name as it always had.  I tried changing the name, just in case, and that didnt fix the problem either.

If I click on the subVI, it will prompt me for it's location.  Clicking on it again, from the prompt, now opens the subVI.  It runs and seems to be fine.  I've made changes and resaved it.  However, each time I open it, I get the dialog box asking where it is again.  This is different behavior than I remember from a few nights ago, but it's tough to tell exactly what was happening then.

In any case, this is a mystery to me.  I've only had this corruption happen twice now, but I'm a little on edge because it doesn't seem to be recoverable.  Now that I can get the subVI open, I guess I could copy and paste the entire block diagram into a new VI.  However, the last time I had the error, I reverted to a previous save and moved forward, so it's orphaned code now.

Still... it's very strange behavior.

[shoneill]

Some points,

Do you have a virus scanner running which may shortly block access while scanning the file?
Is the file on a network with access rights implemented?

Both of these issues have created problems for me in the past, especially when trying to save changes to VIs.

Just a thought,

Shane.

[tbob]

Seems like the link is corrupted.  The best thing to do is to delete the subvi from the block diagram everywhere it appears and then add it again, and rewire the inputs and outputs.  This will establish a new link.

[Casey]

Thanks guys-

For Network permissions:  the file is on the local machine, I have administrator rights, and I created the file, so I don't think it's a permissions issue.

For Virus scanner:  That's an interesting idea.  A virus scanner is running, and I don't have full control to disable it, but that's definitely a possibility.  Seeing how this has happened twice, and both times to the same file, it seems that there is something to do with the file itself that lends it to getting corrupted.

For the corrupt link:  It definitely does seem that the link is corrupt, but the files link with itself is corrupt.  If I just click on the file then I get a dialog asking where it is.  Clicking on it again, this time from inside the "please find the file named..." dialog, now opens the file.  So, it seems that it's link with itself is corrupted.  Weird.  I can relink it to other VIs that would call it by deleting the subvi and reinserting it.  How would I relink it with itself?  I guess pasting the entire block diagram into a new VI would be one thing to try.  I'll give it a shot and let you know.

Thanks for the thoughts.  Any more ideas?

[tbob]

If the subvi is in user.lib or vi.lib or any folder with a file called dir.mnu, sometimes the dir.mnu file gets corrupted.  Happened to me once, and it would crash my system anytime I would right click on a subvi.  Took me three days to find out the problem, after several painful re-installs.  So if you see dir.mnu, beware that this file can get corrupted and cause weird problems.

I think the copy and paste into a new vi will fix this problem.  Unless the block diagram of the subvi contains another subvi in which the link is corrupted.  Then you would have to copy and paste that one as well.

[Chris_Cilino]

Casey,

So I have good news and bad news. The good news is I know the exact cause of the problem. The header information of the VI has become corrupted making it unreadable. The bad news is there is no way to fix this problem.

The two options are to revert to an older copy of the VI (if you have an older copy, fingers crossed) or to rewrite the VI from scratch (boo hiss).

Chris C

Applications Engineering

National Instruments