NI TestStand

Showing results for 
Search instead for 
Did you mean: 

Run-Time Error | Dependent file "Trim Whitespace" is missing

Go to solution

Hello Everyone,


Firstly, Sorry for my English.

Secondly, My name is Marcell and I'm an Engineer in Hungary. I have a problem and I hope somebody can help me.

The problem is the following. We uses NI TestStand for testing method, but we create a new user in Windows, and if we want to start the program we got the following error message:


This test sequence was created in another Windows account, and there is working well. But, if we want to start in another Windows account then we got the above error.

Do you have any idea how I can solve this issue?


Thank you in advance for your help!

0 Kudos
Message 1 of 4
Accepted by topic author Desmond18x

Hello Marcell,


One question : is LabVIEW installed on the computer ? If so, I think a mass compile of the content of the vi.lib may solve your issue.

  • Launch LabVIEW
  • Select Tools » Advanced » Mass Compile...
  • Browse to %ProgramFiles(x86)%\National Instruments\LabVIEW 2019\vi.lib
  • Click on Mass Compile button
  • Have a coffe, a walk, or whatever you want, but it could take some time...


You may have to repeat the operation for instr.lib folder. Optionnally for user.lib (it depends on the code modules dependencies)


The LabVIEW object cache is something stored in Windows user session. So if used to work with an other user, and it do not work anymore with a new user, do a mass-compile in the new session.


Hope this helps,

0 Kudos
Message 2 of 4

Hello Mathieu,


Thank you very much for your help, it really helped. The program is already working well 🙂 

0 Kudos
Message 3 of 4

You're welcome.


Just an additional thought about this issue.


I do encounter this issue, because benches was deployed using LabVIEW installed on computer, as dependencies for codes modules. That's very convenient when you swap from prod to debug, and if a LabVIEW licence is active (LabVIEW itself or TestStand debug). If I remember, we did manage to solve a similar issue without having access to LabVIEW by copying the LabVIEW object cache from a session to another (not proud of it, something I'd prefer to forget 😅)


But in my opinion, and if your code modules are in a "stable" state, a better approach is to have distributable code modules. For example using Project Packed Libraries. You lose the ease of debug, but you will get something far more robust, in that sens your bench will not depend on the Windows session your are using.


Note that recent vesion of TestStand tends to ease the transition from "source" code modules to Project Packed Library:


But even with older version of TestStand (2016), I finnaly packed my code modules into PPL to get something more robust.


You may also use TestStand Deployment Utility, which is able to pack libraries and make relink to generated PPL for you.



Message 4 of 4