Solution
This is a known issue is caused by a .NET runtime and assembly version conflict within the TestStand process.
The problem occurs when a TestStand sequence executes .NET steps that cause a specific version of the .NET runtime and its core assemblies to be loaded into the process. Once this happens, TestStand cannot load a different version of those assemblies later in the same execution.
When the Test Monitor Plugin initializes, it expects a particular .NET runtime version containing internal types it depends on. If a different version has already been loaded by user‑defined .NET code modules, the plugin is forced to use that version and may fail to load if the required types are not present.
Why Running Another Sequence Appears to Resolve the Issue
The issue is not related to running a blank sequence file specifically.
Any sequence that does not execute .NET steps that load conflicting assemblies can be run first and will allow the Test Monitor Plugin to initialize successfully. The failure only occurs when a sequence that loads incompatible .NET assemblies is executed before the plugin initializes.
Recommended Solutions
Option 1: Use Native TestStand Functionality (Preferred)
When possible, replace .NET‑based steps with equivalent native TestStand expressions or built‑in functions. This prevents user sequences from loading a .NET runtime into the TestStand process and fully eliminates the possibility of a runtime or assembly version conflict with the Test Monitor Plugin.
This is the simplest and most robust solution when suitable native functionality is available.
Option 2: Migrate .NET Code to .NET Core
If .NET functionality is required, migrating the code modules to .NET Core can avoid conflicts with the .NET Framework runtime expected by the Test Monitor Plugin. Using .NET Core reduces dependency on shared framework assemblies and provides a more forward‑compatible solution.
NI guidance on this approach is documented in the NET Framework to .NET Core TestStand Code Modules Migration FAQ.