Is it possible that this error shows up for reasons other than truly lack of memory?
If you gorch a network reception or a file read, and then pass that value unquestioned to a function, then it's possible that you're asking to initialize an array with 3,000,000,000 clusters of data, instead of the five it should have been. That will result in the NOT ENOUGH MEMORY message.
You don't really need all that memory, but LabVIEW doesn't know that, since you actually asked for it.
Ways to track this down:
1... Find a way to reproduce it. Does it only happen after 43 days of continuous use? Does it happen after processing 72 files? Find something common between different crashes.
2... Use CONDITIONAL DISABLE SYMBOLS to turn on debugging. Create/Replace a file when the program starts, and open/write/close it BEFORE and AFTER each major operation. Don't use a debugging cache, as the crash will then hide your last few entries - the ones that you need.
3... If you're facile with network stuff, do the same thing but send debugging messages out a TCP connection.
4... Look into the Remote Debugging feature. I haven't used that.
5... Open the TASK manager and watch memory usage: when does it go UP, when does it go DOWN. I found a memory leak this way. I was loading a VI into a bunch of Subpanels, and I was confused about who owned the reference to the VI. When this window came up, the memory usage went UP (by 120-150 MBytes), when the window was closed, it DID NOT go away. 20 or 30 times, and poof!
6... from out of left field comes this one: check for a MilliSecond Timer overflow. Remember that the mSec timer is a U32. That means that it will overflow every 4 billion mSec. IIRC, that's something like 45 days. If you're running continuously, that could happen and maybe confuse something. I don't know when the mSec timer is set to zero - reboot, LV startup, I don't know.
