Using TestStand environments can present limitations in the following scenarios:

  • Multibyte Strings—If the global environment has multibyte strings enabled, then all environments must have multibyte strings enabled. This is mainly because all environments share the Users.ini file of the global environment.
  • User Management—Environments do not support loading an alternate set of users and passwords that differ from the global environment. All environments use the Users.inifile defined in the global environment, which defaults to <TestStandApplication Data>\Cfg\Users.ini.Nevertheless, certain forms of privilege escalation can be accomplished by creating custom configuration folders. For example, a user who cannot normally configure the engine can effectively do so within the context of an environment they create. To accomplish this,the user can create an environment with a custom CommonAppData directory and prepopulate the directory with configuration files.
  • Disable Environments Feature—You can completely disable the environments feature by defining the following registry key:Path: HKEY_LOCAL_MACHINE\SOFTWARE\National Instruments\TestStand\, or 64-Bit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\TestStand\Name: DisableTestStandEnvironments

    Type: DWord

    Value: 0x1

    An error will occur if you enable this registry key and launch a TestStand application that attempts to use an environment other than the global environment. This setting applies to all installed versions and bitnesses of TestStand.
  • Remote Engine—The TestStand remote engine does not support environments. The remote engine always runs in the global environment.
  • Simultaneous Execution—Although it is possible to run two or more instances of the TestStand engine simultaneously in different environments, the instances are not completely isolated from each other. Certain features of TestStand are shared at runtime, and could conflict. For example:
    • Out-of-process synchronization objects are global to the system and not scoped by environments. (In-process synchronization objects are private to the process and therefore cannot conflict across environments.)
    • Out-of-process execution for LabVIEW and CVI Adapter steps will generally occur within a single shared instance of the external LabVIEW or CVI ADE. (In-process execution remains private to the process, so it cannot conflict.)
    • 64-bit TestStand applications configured to use the 32-bit NI Switch Executive (NISE) share a single instance of the out-of-process NISE. 64-bit TestStand applications configured to run NISE in-process will not conflict. 32-bit TestStand applications always run NISE in-process, and therefore cannot conflict.
    • When debugging, stepping into a code module from an adapter step can use an existing instance of the external ADE already in use by a TestStand application running in a different environment.