Leaderboard

I had a similar problem, I had a long running LabVIEW executable that I noticed was typically was using over 2G's of memory on the PC after a couple of days. After spending a morning very closely looking through the code I managed track down a number of ref's I was failing to close and by closing all my references I got back down to a more reasonable memory usage that did not grow larger day by day.

A few questions: Was the source code originally created in LV2013, or a previous version of LabVIEW? Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code? Is the crash intermittent? Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV) Are you using .NET callbacks anywhere? What additional libraries (NI and third party) do you have installed? Is dev environment in a VM or on bare metal? If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur? Have you tried removing mutation histories from all LVClasses? If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur? Have you tried DETT in the offending context? Have you tried Procmon filtering on LabVIEW.exe events? Your issue sounds eerily similar to an issue that I'm incredibly motivated to put to rest myself, riddled with red herrings.

Two tips -- the TestStand Deployment Utility has a simple command line API for building deployments (and even installers), and I've talked with devs who successfully use TestStand sequences as functional/unit tests not only in the build environment, but also deployment environment (a particularly clever use of TestStand!)

Agreed, though it's not inherently secure, rather it offloads the security to how the user handles the key. I'd say it's the most secure way software could handle it, but an uneducated or lazy user could still result in no better security than plain text. Whole different subject indeed. Suffice it to say I would appreciate a "secure" data type where buffers are strictly managed and not copied at a whim. I shall not hold my breath...

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way. So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself). Many apps will store something in a file so that users don't have to keep entering the info. This should never be plain text, rather a hash of the password or the password with other stuff combined (SHA256 or SHA512 are quite common-don't use MD5), but this assumes the adversary will either not have access to that hash or will not be able to hook into the software where the key is used if they do get their hands on it. It's more of a case of "security through obscurity" than "secure".since whilst they may not be able to recover the original plain text directly, they may be able to inject the key, look it up on a public database or use it at some point in the applications process space. When used in this way, the key will usually be the result of not only the password, but the password combined with a salt. This, in essence is just another obscurity layer but means that two pieces of information are now required to reconstitute the original. It will, however, be for naught if they are both stored in the same place (a website, for example will store the hash in the DB, but the salt in a file). Software is a tricky beast since if a competent adversary has access to the machine, then all bets are off!.It's just a matter of time, persistence and budget.

I don't have an answer for you, but I just wanted to point out that string constants would be scrambled in a part of the VI. It'd be hard to see the encryption key -- you'd need to know what part to get out, how to get that part, and how to unscramble it -- but it's not there in plain text. If that's suitably secure for you, then go for it. But I'd recommend against it

On secondment? Lol

Hey Jon... you coming back to Labview or just stopping by for a visit?

An LVLIB loads all its contained libraries and classes, but not its VIs. So it is OK to have lots of VIs in a LVLIB, even if not all will be used. It is only LVCLASS that loads all contained VIs. Note that if you have a class in a LVLIB, loading the LVLIB will load the class and thus all the class’s VIs. I generally do not put classes in libraries for thus reason. NI really should work at changing this. I can see why it might be necessary to load all dynamic-dispatch VIs, but not static ones.

NI does that intentionally just to see if you're paying attention. They can tell when they hear the "crash".....