Memory Limits of TestStand Systems


The amount of memory available to a test system is determined by several factors, including operating system limitations, bitness of the test system process, and whether code modules are being executed in-process or out-of-process. This document explains these factors so that you are aware of how your test system configuration affects the amount of memory your test system can use during execution.


Operating System Memory Limits

The Windows operating system enforces memory limitations on the amount of memory available to a process running on the system. These limitations are affected by the bitness of the operating system and the bitness of the process. The table below lists the amount of memory available to a process based on these factors.

Process Type 32-bit Windows Operating System 64-bit Windows Operating System
32-bit Process 2 GB* 2 GB*
64-bit Process N/A 8 TB

*This limit can be increased by setting the Large Address Aware flag for the process. See the section below for more information.

Increase Memory Limitations

Large Address Aware Flag

If you are running a 32-bit process, you can increase the amount of memory available by configuring TestStand to be large address aware. Enabling the Large Address Aware flag will increase the maximum available memory to 3 GB for a 32-bit Windows OS, and 4 GB for a 64-bit Windows OS. For more information, refer to Use Large Address Aware Flag for 32-Bit TestStand Processes.

Out-of-Process Execution

Because memory limitations are imposed on each process individually, you can use out-of-process execution to increase the amount of memory available to the test system. Executing a portion of test code in a separate process will allow that code to access a separate memory space from the memory being used by the rest of the test system. There are several ways in which you can implement out-of-process execution in your test system architecture.

Execute Code Modules Out-of-Process

If your test system contains code modules which require a large amount of memory, configure the code modules to execute out-of-process to access a separate memory space from the TestStand process itself. This increases the amount of memory available to the code modules and lessens the likelihood that an out-of-memory error will occur during execution.

The LabVIEW and LabWindows™/CVI™ module adapters can be configured to execute code modules out-of-process. For more information, refer to Use 64-Bit TestStand to Execute 32-Bit LabVIEW Code Module.

There are two downsides to configuring the adapters to execute code modules out-of-process:

  1. Execution Speed – Executing code modules out-of-process is typically slower than executing code modules in-process. Out-of-process execution requires the TestStand Engine to communicate with the external process to instruct it to execute code.
  2. Licensing – The development version of LabVIEW or LabWindows/CVI must be installed on the test machine to execute code modules in one of these environments. This requires a development license for each test machine. 


Execute a TestStand Sequence Out-of-Process

In TestStand 2014 and newer, you can configure a test sequence to execute out-of-process in a separate instance of TestStand running on the same computer, which allows the sequence to access a separate memory space from the original TestStand process. You can also use this approach to execute a sequence in the opposite bitness of TestStand, although this approach requires both 32-bit and 64-bit TestStand to be installed on the computer. For information, refer to Execute TestStand Sequence Across Bitness.

Note: Using remote sequence calls to execute test sequences out-of-process has a performance penalty compared with in-process execution. It is also more difficult to debug a sequence executing out-of-process.

Effects of Approaching the Memory Limit of a Process

It is important to recognize that an out-of-memory issue could occur before the memory limit of the test system process is reached. As the test system executes, blocks of memory are allocated and used to store code modules, variable values, and other data. When the code modules are later unloaded or data is cleared, the blocks of memory are deallocated and become available for use.

The result of this allocation and deallocation is that the free memory space of a process often exists as multiple smaller blocks of memory spread throughout the total memory space of the process. This concept is known as memory fragmentation. Memory fragmentation can result in an out-of-memory error if the process attempts to store a large array or other piece of data in memory and is unable to find a free block of memory that is large enough to store the data.