LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fixing corrupt VI

Solved!
Go to solution

I was able to recover mine, so I thought I would share. This will not work in all cases like the poster submitted in http://forums.ni.com/t5/LabVIEW/vi-corrupt/td-p/1256628 where there was a resultant 'Generic Error' dialog, but seems to work on the type where LV just goes 'poof' when you try to open the front panel of the corrupted VI.  Maybe like Mike Porter's commenting about in LV2011 here: http://forums.ni.com/t5/LabVIEW/is-there-a-way-to-recover-a-damaged-VI/m-p/1863387

 

I was working in the block diagram of a simple, single VI in LV2010, just cleaning up some wires, when LV went away w/o any dialog box or warning.  I found the autosaved copy and my original from the start of the day corrupted.  Any attempt at reopening either VI also resulted in LV disappearing without leave.  I also wasn't able to load it via the VIServer and then programatically pop up the BD...

 

This was my work around:

I opened a new VI in LV.  On its blank BD, I selected to add the corrupted VI from the 'Select a VI...' entry at the bottom of the Functions palette.  To my surprise it let me add the VI.  Its icon was visible, but any attempt to access the front panel caused 2010 to puke.  I then decided to use the 'Find and Replace' search to look for a function ('Add') that I knew was in the corrupted VI's BD.  The BD of the corrupted VI popped up intact when I double clicked a result in the 'Find' dialog.  I was then able to cut and paste chunks of the BD to a new VI and save it.

 

Hope this comes in handy for someone.

0 Kudos
Message 11 of 17
(3,057 Views)

Very impressive, thanks! I already rebuilt this some months ago, but any chance of sharing your secret magic wand? 🙂

0 Kudos
Message 12 of 17
(3,057 Views)
Solution
Accepted by topic author Klox

The working technique in this case was to progressively replace bytes in the beginning of the file with corresponding bytes from a new blank VI. Looking at the results, it appears 16 bytes was the magic number in this case.

Message 13 of 17
(3,047 Views)

Thanks! I wish I could have marked this one as the solution now. I just did a manual adjustment with notepad++ and it worked for me too. I can't remember everything I tried, but I definitely tried doing some hex adjustments. I guess I didn't take it far enough.

 

Cheers!

 

edit It looks like I could change the solution 🙂

0 Kudos
Message 14 of 17
(3,038 Views)

I had the same problem...

I opened the files in Vim and noted that at the end, "a.vi" was missing when i compared it to a file saved with the same name...i added those and it, magically, came back to life!!

from this...T999_0-1625262316796.png 

 

to this....T999_1-1625262341300.png

 

literally, magic...?

0 Kudos
Message 15 of 17
(2,183 Views)

No.  Literally, "binary edit".

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 16 of 17
(2,171 Views)

I was just pointing out my magical luck 😉

not knowing what got corrupted and editing those bits seemed a bit too easy to believe 😛

but I guess one could say, "literally, moving electrons around..."

hmmm...does that make me an "electron whisperer?"

Message 17 of 17
(2,092 Views)