We've been having this problem off and on, just had it again. We run long duration tests, >24 hrs frequently. When we have the error, it is pointing to "get property value (string).vi" in one of our vi's, which is in a loop and constantly reads this property for much of the test. I believe I have a separate thread on this somewhere but I decided to post here because this sounds like our problem exactly. We are using LV 2011 SP1 (32 bit), on a windows 7 64 bit os. Any insight? We get it rarely any more, but it just happened again and does screw our test up.
We have similar issues with Test Stand 2014 and Labview 2014. Latest is with one of the high end Lab PCs, the test has been ran for more than 12 hours. It ran out of thread in the middle of the sweep. Station still reports having more than 11G of RAM out of 16G of RAM available, both test stand and labview consumes reasonable amount of memory, does not look like a memory leak. There are 16xx thread running compare with a freshly booted PC without test stand and labview running of 14xx threads.
Once this error happens, you cannot do any operations in test stand, even save the file. Since Test Stand does not have a thread limit, I have been looking at Microsoft website for thread issue, most direct to VM Manager (error 2912). The fix is stop and re-start the service. Manually tried that, but once these settings comes into effect, it want to reboot.
Anyone else have a good suggestions beside breaking down the test, make the test run shorter, before the limit hit?
While you are running your sequence, if you look at the number of threads used by teststand and by labview, is one or the other of those steadily climbing? For example, if you let it run for 10 minutes, check the number of threads, and then let it run for ten minutes and check the number of threads is the number of threads in one of the processes continually climbing?
The answer is no. I have been monitoring a station for a few hours, the thread and handles count in the system will cycle up and down, nothing out of ordinary. When the running out thread error happens, I do not see any abnormalies. Here is some windows statistics.
Below is the PC health when thread error ocurred.
Below is when the PC is just been rebooted.
Below is when the sequence is running.
I recommend looking at the per-process number of threads in the process list (you can add a column for it if needed), and see if that number is steadily going up in either TestStand or LabVIEW. Also what is the exact error message you are getting. Perhaps a screenshot of the error dialog if possible.