11-05-2014 05:40 AM
We noticed in TestStand 4.1 that when we use "Call Executable" on a batch file:
We can work around the first issue by using CloseHandle (from kernel32.dll) on RunState.PreviousStep.ProcessHandle, but I would like to know whether these are known issues and are addressed in later versions of TS.
Best regards
Peter
11-05-2014 12:24 PM - edited 11-05-2014 12:27 PM
In later versions of TestStand, the default behavior of a new callexecuteable step is to NOT store the process handle at all (instead it gets closed immediately). There is a setting for whether or not to store the handle and an expression to specify where to store it as shown below:
For the GDI object leak, are you seeing a leak in the TestStand process or is the GDI object leaking because the handle hasn't been closed yet, so the other process is still around and still using GDI objects? Does the GDI leak go away if you close the process handle? If you call callexecutable in a tight loop does the number of GDI objects grow unbounded or does it level off (i.e. is it really a leak or a one-time allocation)?
-Doug
11-05-2014 12:44 PM
Thanks for the quick reply. I found the setting in TS 2012 but thank you for the clarification of the behavior.
As for the GDI leak, I have to reproduce the situation as this was a while ago on a machine in the field and we fixed it using the "minimized" approach. I will get back as soon as I tested it.
Regards
Peter