There's a couple of things that cause this... The most likely cause is a case of 'bitness' mismatch, e.g. you have a 64 bit web application trying to use the 32bit TRIM DLLs.  Is it possible you installed the wrong TRIM runtime on the UAT server?

Has your application (API) been built for 'AnyCPU'?  Are you hosting the application with IIS? Does your IIS pool allow 32bit applications?  If so then it's possible the web application (API) is running in 32bit mode.  When an 'AnyCPU' binary is executed on a 64bit Windows OS, the OS will decide whether to run it as 32bit or 64bit.  It may be deciding to run as 32bit and the TRIM SDK will fail to link to the 64bit TRIM runtime DLLs.

Your web application (API) will be executing with the permissions of the IIS pool account.  Does that account have access to the directory containing the TRIM runtime DLLs?

I just remembered another possibility:  The UAT host is missing a DLL that is required by the tsjapi.dll.  Missing dot net runtime perhaps?  Try checking the dependencies of tsjapi.dll with something like the dependency walker utility.

Stack trace looks to show the Initialise method is being automatically called.

Does setting the TRIMApplicationBase.TrimBinariesLoadPath (static property) manually and then calling TRIMApplication.Initialize() (static method) result in any different errors?

Normally the Initialize is called implicitly under the hood when the first native backend method is called but sometimes calling it manually can give a more detailed message.

There is also a TRIMApplicationbase.DiagnoseDllLoading(binariesdir, systemDir) static method that can be called which has helped me in a pinch or two.

-Scotty

Thanks to everyone for all your suggestions!

It turns out the brand new UAT server did not have a c++ redistributable installed, so there were a number of System32 files that were missing, which the TRIM.SDK was looking for. The Dev server has this installed.

We found this by looking at the TRIMApplicationBase.DiagnoseDLLLoading() method, and the list of .dll files it was trying to load, and found a few were missing, including vcruntime140.dll

Once we downloaded and installed the latest c++ redistributable, the website began to run again.