"memory is full" "error code 23" "not enough memory to complete this operation"

[MF]

I was working in LabVIEW 8.2.1 on Windows XPand I accidentally kicked the power cord to the computer. The machine rebooted and I proceeded to get back to work. Upon clicking on my main VI, I was dialoged with 2 message screens, the first saying that the "Memory is Full" and "Error Code 23". The other dialog box said "Not Enough Memory to Complete This Operation". I kept receiving these error any time I tried to open the VI. I was able to open all other VI's in the directory but not the main VI. Here is a list of things I tried to do:

1) Re-install LabVIEW 8.21 - no change
2) Try to open the software on another machine with LV installed. I tried 3 other machines. None of them opened the software however, one of the machines gave a "Tried to stop the LV Realtime Engine" error message instead of out of memory error.
3) Mass Compile the directory. Still not change

I have read all of the posts about memory and array sizes and all that but I am running a very clean code with Queue Based State Machine architecture and no local variables, etc. The total source code for the main VI is 570 kB. 

My big problem is that I do not have a backup of this source and unless I can open it, it will be lost and I will have to re-create a lot of work. If anyone has a suggestion  or solution, I would like to hear it. I am attaching a copy of the source code less sub-VIs. Thanks.

Michael

[RDR]

Hello Michael,

I cannot open the VI at all with LabVIEW 8.2.1 or LabVIEW 8.5.  It seems that some corruption must have occurred with the file when the power was lost on the PC.  I am sorry, but it seems the best route is to re-write the VI.

-Bob

[MF]

Hello Bob,

Thanks for trying but certainly you guys at NI have more powerful tools than LV to recover VIs. I used a binary editor and found that there are 4 instances of this ASCII string "RSRC". In normal VIs there are 2. After removing the first header section, I was able to open the VI (I saved original) but unfortunately, it was not the correct VI. It seems that during the power outage, two VIs were mashed together. If I knew the binary structure of a LabVIEW VI, I probably could pry the 2 VIs apart but since this is probably proprietary info, only NI could do that.

Don't you guys have a tool to recover files besides DeCorrupt? Is there a reason that LabVIEW is so unstable after all of these years that files cannot be recovered as even Microsoft is able to do with Word/Excel/etc.? Come on you guys, it took years until you had Undo but programmers respected you so much more after that. While I take precautions to save and occassionally backup, I did not in this instance and all work is completely lost, not just a day's worth of changes. Maybe you could build in a backup system in addition to your automatic save options.

Thanks for almost a great product.

Michael

[RDR]

Hello Michael,

We do have an Auto-Save recovery system in LabVIEW.  However, it appears this specific VI is corrupt as a result of your power loss.  Did you by chance check the 'LabVIEW Data' folder in your 'My Documents' to see if a copy of the VI was saved there?  I am sorry this has happened, but I assure you we have taken measures in LabVIEW to implement an Auto-Save function.

Regards,

-Bob

[AnalogKid2DigitalMan]

Michael:

Even a backup system would not be of any use in the event of a hard drive failure, fire, flood etc. Always back up to alternative locations physical, be it a network, CD, thumb drive, whatever. Not trying to reprimand you, just that I can relate to your unfortunate situation. When I was a co-op I lost a day's work when another person tripped over the power cord to the PLC I was programming. I was fortunate to have learned the save and backup often routine that day while still in school and have only lost a couple hours of work since in the past 22 years.

[MF]

Hello Bob,

Can you explain Auto Save to me? Here is what I assumed the function did:

1) Saves your work either before running the VI or every x minutes
2) Prevents you from Undo'ing any changes before the Save
3) Same as clicking Save

The reason I did not want to use it is because I sometimes go down one route and find out that it was not so good so I undo many changes. I set the default for undo'ing changes to 50 to 60. I also do not want to save changes to files that I go into, keep open, but do not intend to save any changes.

If the save is just for helping to recover damaged files or applying changes to a file if the file is closed due to runaway LV or other such anomalies, that is what I would really want. Saving changes to a permanent file should be up to the user.

Let me know if I am incorrect about the assumptions. As for the file, I still believe if you use LV program with debug option on, you should be able to find the precise problem in the binary source file and correct it and eventually build a file recovery program. I mean, the source is there but may just be missing a single character somewhere inside it. I don't ever want to go back to ASCII source code but at least ASCII is more stable.

Michael

[RDR]

LabVIEW automatically saves files before an irregular shutdown or system failure.  It does this by saving open files at specified intervals and in the event of an irregular shutdown or system faluire, the 'Select Files to Recover' window pops up to display recoverable files the next time LabVIEW is launched.  This window allows you to compare the latest automatically saved version of the file with the file listed as a recoverable file, this will open both versions and allow you to choose the version to keep.  There are also options for discarding recovered files, etc.  Basically, there is another copy of the file saved as a backup for the case when you lose power, once you restore LabVIEW you have options to choose a backup copy or your "original".  In your case, the "original" is corrupt and since the auto-saving was disabled, there is not a backup to use in place of the corrupt file.  I am sorry this is the case, I would of really liked to everything working for you.  Please consider using the auto-save for recovery in the future.

-Bob

[MF]

Thanks Bob, I will implement "Auto Save" all the time. It works as it should and not the way I thought it worked. Thanks for your help.

[Jolty]

My two cents...

I've had a similar experience with a laptop that was intermittently unable to switch to battery when unplugged from the wall.  Being aware of this problem, I would save my work, then unplug from the wall.  If the laptop crashed upon unplugging, then you'd think I'd be OK, right?  WRONG!  Upon re-booting, the last saved vi could be corrupted and would give errors when trying to open it.  The vi would be totally useless and would have to be restored from backup or rewritten.  I think (but am not positive) that the problem may be due to Microsoft's "Write Cache Enable" on disk drives.  I think that what happened is that my last save never made it to disk but only to the cache which was then blown away upon the hard crash. 

This cache can be disabled via the Device Manager.  Goto the properties page for every hard drive listed in the Device Manager.  Under Disk Properties uncheck the "Write cache enabled".

But then again, I may be barking up the wrong tree...

[Jolty]

It happened again to me: my laptop crashed when I unplugged it from the wall and my last saved vi became corrupt.  This corruption happened even though I had the "Write cache enabled" unchecked in the Properties of the hard drive.  I'm going to have to re-write the vi.  Going forward, I'm going to try using a SysInternals (free) utility called Sync which flushes the disk cache to the hard drive.  You can find it on the microsoft site - http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx