From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-07-2014 11:29 AM
Hi,
While running on a test station using the teststand deployment, TestStand randomly crashes by the end of the sequence execution and a pop-up appears to specify: testexec.ini access denied... More precisely, it crashes between the end of my test sequence and before the "PASSED"/"FAILED" pop-up appears... Afterward, the testexec.exe just crashes and kills all remaining execution as the application closes...
When I go to my \cfg files, I can found a file INI$$0.TMP and if I compare it with the Testexec.ini file, they are identical and with the same date/time....
I should also precise that, this morning, the issue occured after the 8th consecutive execution... Therefore, this is not a write/access permission issue... Anyway, I configured windows to provide the "FULL CONTROL" permission on my test engine directory / deployment directory (including the cfg dir) which is located to "C:\ATE_Teststand_engine\".
I really need to get this fixed as soon as possible... Is there a way to prevent teststand updating this file after each execution?
PC Configuration:
Win7 SP1
Teststand 2013 base deployment
Labview 2013 f2 runtime engine
Thank you for help!
C.
11-07-2014 02:35 PM
It looks like you have your cfg files in a different location than the default cfg folder. You have to point it there using the station options.
Look in Configure>>Station Options>>Preferences tab. Is that set to your cfg folder?
11-07-2014 02:55 PM
Hi jigg,
You right, my config files are located at "C:\ATE_Teststand_engine\Cfg\", but my station options are configured accordingly... Furthermore, as mentioned in the issue description, the problem occured on the 8th consecutive execution, so the files should be loaded properly...
«« Look in Configure>>Station Options>>Preferences tab. Is that set to your cfg folder? »» yes
Maybe some additionnal info:
I use the Sequential process model
I run 3 instances of the test, i.e. I pressed "Test UUTs" 3 times. However, when the problem occured, only 1 thread was terminating, the others were running my sequence...
I use a custom opertor interface, but based on the teststand simple operator interface.
11-07-2014 03:04 PM
Try reproducing the issue with the UI that ships with TestStand. If you cannot reproduce then that leads me to believe it is your custom UI.
So are you just pushing the Test UUTs button while the other executions are running? That seems like an odd thing to do. My guess is that you are getting a race condition where one of the threads is trying to change testexec.ini and another thread goes to access it but cannot. Then you might get some sort of deadlock situation which is why your other thread is still running after termination.
If you want to terminate the other theads you have to have their execution selected by the executionviewmanager. Otherwise the buttons (i.e. terminate) only applies to the current exeuction selected by executionviewmanager.
Hope this helps some,
11-07-2014 03:39 PM - edited 11-07-2014 04:04 PM
ok... Any idea to prevent it?
Is there a way to set a "lock" step somewhere when the file is read or just prevent modifying the testexec.ini? Since the file is now configured, I don't care about saving the latest config or change due to the execution as loaded vi, etc... Where is the TestExec.ini updated in the process model?
Thank you
C.
11-08-2014 08:41 AM
Did you reproduce it in the shipping UI? I'm not totally convinced it is a race condition. It is most likely the engine that is updating it if anything. Or your code is changing some setting that updates it. When I create a simple sequence file with just a popup in it and try what you are doing in the full featured UI that ships with TestStand I don't see this issue.
You need to try and isolate the issue before throwing random locks around. Do you know what the call stack is when you see it? Which step is reporting the error?
11-10-2014 08:14 AM
Ok, I will try to pinpoint what generates the issue. However, this could be difficult, because it occurs randomly, and the UI crashes and closes so I can't see the call stack or steps in the debug window...
I'll follow-up with you when I will have a better idea of what's going on.
Thank you
C.
11-10-2014 08:34 AM
What version of TestStand and what OS are you using? There was an issue that occurred on Windows 7 (and likely newer OSes as well) that was worked around in TestStand 4.2.1. See issue ID 193203 here: http://zone.ni.com/reference/en-XX/help/370052M-01/tshelp/infotopics/421bugfixes/
Hope this helps,
-Doug
11-10-2014 09:29 AM
Hi Doug,
Here is my config;
Win7 SP1
Teststand 2013 base deployment
Labview 2013 f2 runtime engine
thank you
C.
11-11-2014 08:38 AM - edited 11-11-2014 08:46 AM
In reading what you wrote more carefully, it sounds like you are seeing random crashes, not just the testexec.ini error. That sounds like you might have a memory corruption bug. Do you always get the testexec.ini error, or only sometimes? Do the crashes happen first, or the error? Are you getting any other errors? Can you debug your UI and see where it is in the UI code/thread when it crashes?
-Doug