- Open Task Manager by entering Ctrl+Shift+Esc.
Task Manager will launch. Click the More Details button at the bottom of the Task Manager dialog to display the full set of options.
- Navigate to the Details tab.
The Details tab contains a list of all running processes on the system as well as a set of information about each process.
- To configure the display settings for Task Manager, right-click on a column header and click Select Columns.
For memory growth issues, it is often useful to enable the Memory (Private Working Set), Handles, Threads, USER Objects, and GDI Objects columns. All these metrics are a snapshot of the resources currently used by the application. The following table explains the meaning of each column.
|
Column
|
Description
|
|---|
|
Memory (Private Working Set)
|
The set of virtual memory that is currently loaded into physical memory. Does not accurately represent the entire private memory space that a process may be using.
|
|
Handles
|
The number of object handles in the process’s object table. Maintaining references to instrument driver sessions, loading LabVIEW VIs, and many other operations can cause the number of handles to increase.
|
|
Threads
|
The number of threads running in the process.
|
|
USER Objects
|
The number of USER objects currently being used by the process, which can include objects such as windows, menus, cursors, and other internal objects.
|
|
GDI Objects
|
The number of objects from the Graphics Device Interface (GDI) library currently being used by the process.
|
- Click OK. The Details table updates with the values of the newly added columns.
- Locate the process of interest to view information about the running test system.
For TestStand, the name of this process is SeqEdit.exe if you are executing your test system in the TestStand Sequence Editor, or the name of your user interface (such as TestExec.exe) if you are executing your test system in a user interface.
Note: If you are executing code modules in an external process, such as LabVIEW.exe, then the memory growth may occur in that process as well.
- Execute your test case. Make note of the value of each column at the start of execution.
- Allow the system to run for a longer period. Compare the current values of each column to the values you observed at the beginning of execution to determine if significant growth has occurred in any of the column values.
Note: By executing the test code in a loop using the Test UUTs process model or by looping within a sequence, you can more easily detect memory growth that may be occurring during the execution of your test system. During this process, you may see memory growing and then resetting. Sometimes, this is a result of .NET garbage collection.
You may experience out-of-memory errors even if values in the Task Manager columns are below the memory limit of a process on a Windows system. This discrepancy is often due to differences between how much physical memory a process is using versus the virtual memory a process requires.
Physical memory is the physical set of RAM on the system, and is likely to range in size from 4GB to 16GB or more. This is the total physical memory available for use by all processes on the system. The operating system manages how processes use physical memory.
Virtual memory is the memory space available to an individual process, and can range from 2GB to 4GB for a 32-bit process, or up to 8TB for a 64-bit process. Virtual memory is the limiting factor of memory available to a process, so a 32-bit process can only access a maximum of 2-4GB of memory, even on a system with 16GB of physical memory installed. For more information on virtual memory limitations, refer to the
Memory Limits of TestStand Systems document.
When you are examining the memory values in Task Manager or any of the other tools described in this document, it is important to understand whether the value is a count of virtual memory or physical memory. For example, the
Memory (Private Working Set) column in Task Manager displays the amount of a process’ virtual memory that is currently loaded into physical memory. Since this value is not indicating the total amount of virtual memory being used by the process, it is not an accurate indication of how close the process is to its total memory limit.
For this reason, when examining memory counters in Task, you should consider how the counters are changing over time rather than focusing on the absolute value of the counters.