TestStand calling a CVI DLL - Working Directory Problem?

[CIM1]

This is a hybrid TestStand/CVI question so I am posting it here first...
 
I have a TestStand 8.1 sequence calling a CVI 8.5 dll. The dll loads .hws digital pattern files from disk. These are normally picked up relative to the path where the dll resides.
 
However an intermittent problem occurs when the dll is called from TestStand, sometimes the file load fails.
 
Turns out when the error happens, the path (Current Working Directory?) is being changed from that of the called .dll to that of the TestStand directory (C:\Program Files\National Instruments\TestStand 4.1). Once it goes wrong, it stays wrong in subsequent executions.
 
I read in the CVI help that when calling File I/O from more than one thread, the OS does not maintain a separate working directory for each thread. Not sure if this is what is going on - can the dll's caller (TestStand) mess with the Current Working Directory that the dll uses?
 
I am not clear whether this is a TestStand issue or a DLL design issue. TestStand also crashes when I unload all modules after this error condition occurs, suggesting perhaps there is more bad stuff going on "under the covers"...
 
I should also explain this sequence has a customised process model for use with an Operator Interface but this problem is seen while running from the TestStand sequence editor.
 
 

[Scott Richardson]

To CIM1 -
TestStand does set the current working directory and typically tries to reset it back when load a DLL, and I think when calling code modules. Other modules could also set this directory. I would not recommend relying on the current working directory in any application, especially TestStand, because there are too many players that could mess with it.  CVI has a nice function to get the path of the DLL that you can use to build the path to find a file in the same directory of the DLL. This is what I have used in the past.

char modulePath[MAX_PATHNAME_LEN];     GetModuleDir (__CVIUserHInst, modulePath);
Hope this helps.

[CIM1]

Thanks Scott, I temporarily fixed it by using a call to the windows kernel to set the current working directory in the TestStand sequence but I will pass on your code to the DLL creator - clearly it is unsafe to assume that the path will not be changed by some other process.