Here's my setup:
Custom .NET AnyCPU (inspecting the assembly shows that it supports addresses larger than 2GB) monitoring application that uses SyncManager API (TSSync.Interop) to dequeue a SequenceContext object. During the dequeue, the destination object is of type PropertyValueTypes.PropValType_Reference.
The Enqueue (by reference) of the SequenceContext happens from a model plugin sequence executing with the TestStand 2017 64-bit engine.
The Enqueue happens with no issues. The DeQueue times-out.
Summary of Results:
If I run the .NET application as a x64 with 64 bit engine, then the DeQueue operation works
If I run the .NET application as AnyCPU with 32 bit engine, then the DeQueue operation works.
If I run the .NET application as AnyCPU with 64 bit engine, then the DeQueue operation times out.
In all cases the TSSync.Interop assembly is the same, which is a 32 bit assembly which can handle 32-bit words according to the PE header Flags.
Solved! Go to Solution.
NI Support ended up helping me. The solution to the problem was to ensure "Prefer 32-bit" was turned off in the project Build Settings.
We have discovered, that the true root of the problem was our process model plugin and our external application. Our process model plugin supports either 32 bit or 64 bit usage and our external app was built AnyCPU. The important key to making it work was found in the TestStand help: "When the Synchronization object name begins with an asterisk or computer name, you can use a 32 or 64 prefix to specify using 32- or 64-bit TestStand to host the out-of-process Synchronization object. For example, the name 64*syncobj specifies a Synchronization object called *syncobj in the 64-bit TestStand host process, even when used from 32-bit TestStand. Use the prefix to share Synchronization objects between 32-bit TestStand and 64-bit TestStand in the same host process. If you do not use the prefix, 32-bit TestStand hosts out-of-process Synchronization objects in a 32-bit process, and 64-bit TestStand hosts out-of-process Synchronization objects in a 64-bit process."
Once we added a conditional check in our sequence step to check "is64Bit" property we could then use a "32" or "64" prefix for the Synchronization object name. Later, in the external application, the TestStand API call then was able to properly get a handle to the object and dequeue the data we had stored.