TestExec.exe behaving like a DOS TSR (for those that remember!)

[chromaburst808]

Hey there,

Here's an interesting one.... why is it that the pre-built TestExec EXEs that ship with TS 3.5 seem to execute differently when unloaded under Windows XP?

I'm using LabVIEW 7.1.1, TestStand 3.5, XP SP2

These unload correctly:
C:\Program Files\National Instruments\TestStand 3.5\OperatorInterfaces\NI\Full-Featured\C++ using MFC\Release
C:\Program Files\National Instruments\TestStand 3.5\OperatorInterfaces\NI\Full-Featured\CVI

These do not:
C:\Program Files\National Instruments\TestStand 3.5\OperatorInterfaces\NI\Full-Featured\CSharp\bin\release
C:\Program Files\National Instruments\TestStand 3.5\OperatorInterfaces\NI\Full-Featured\LabVIEW
C:\Program Files\National Instruments\TestStand 3.5\OperatorInterfaces\NI\Full-Featured\VB.Net\bin\release

Using Sysinternals Process Explorer, it would appear that the LabVIEW, C# and VB. Net EXEs all remain in memory. I discovered this with our LabVIEW OI after running a batch of tests and sometimes exiting the OI to make hardware configuration changes.

The following artiicle makes some reference to modifying the LabVIEW OI to deal with using a command-line approach to running TS sequences:

"unload TestStand Operator Interface " - this is on the French TS forum.
http://forums.ni.com/ni/board/message?board.id=4170&message.id=5486&query.id=26662#M5486

The rough Babelfish translation as follows:

"I call upon Operator Interface of TestStand in a management tool of tests, via a batch, by the order: call "C:\Program Files\National Instruments\TestStand 3.1\OperatorInterfaces\NI\Full-Featured\LabVIEW\TestExec.exe" - runEntryPoint "Individual Pass" %1 - useExisting - quit This batch is called upon in various scripts which make a campagen of tests, and it must close the interface once the sequence slips by carried out (option - quit). Therefore, for a campaign, there are N ouvertures/fermetures of Operator Interface. The problem is that progressively, all the sequence files accumulate in memory. It is possible automatically to discharge them at the time of closing of Operator Interface, i.e. to carry out the operation of the menu [ File: Closed All Sequence Files and Executions ]?

This behavior can be obtained by modifying the interface LabVIEW operator in the following way: one VI callback must be added to under VI "Configures Callbacks.vi Vent" associated with the QueryShutdown event with the Manager Application. In this new VI callback, it is then enough to call upon the CloseAllSequenceFiles method of the Manager Application."


Since I am not using this cmd-line approach for running my sequence, do I still have implement it's suggestions to kill a custom LabVIEW OI?

-Chroma

[TerryS]

Hi Chroma,

I haven't been able to duplicate this.  I downloaded the Sysinternals Process Explorer and opened the TestExec.exe that was built in LabVIEW.  TestExec.exe shows up within the Process Explorer and when I close TestExec.exe it is removed from the Process Explorer.  Can you provide some more information on the exact steps you did to witness this behavior, so I can try to duplicate it?

[chromaburst808]

Terry,

Thanks for your reply. There's not really any special set-up to exhibit this behaviour on my machine. Start any one of the OI's mentioned, kill the OI with my sequence loaded (or unloaded) via File >> Exit or via top-right Window exit - the EXE stays in memory.

I'm loathe to completely rebuild my development machine, however I will try an fresh TS installation on another machine.

-Chroma

[TerryS]

Hi Chroma,

I have still been unable to duplicate this.  Have you tested these OI's on another machine?  Did you see the same behavior?

[chromaburst808]

Some more details....

I've noticed that the when the LabVIEW testexec.exe exits cvidbgi.dll and cviauto.dll exit fine, but the cvirte.dll remains. This led me to think that the CVI RTE may be corrupt, hence I tried to repair it (no joy!). Uninstalling is also problematic, as it requires to uninstall TS 3.5 also...

-Chroma

[TerryS]

Hi Chroma,

Is your sequence calling CVI code modules?  Do you still see this behavior if you start the LabVIEW TestExec.exe and close it, without running or opening any sequence files?

[chromaburst808]

Hello Terry,

No my code is pure LabVIEW 7.1.1, no CVI calls apart from those in the sequential model. My original debug attempt was to just load the OI without a sequence behaves exactly the same. I've rebuilt EXE using the NI and my User copy.... still behaves the same.

I've noticed one interesting thing about the slain OI (still in memory) using Process Explorer. The context switch for one ref to the lvrt.dll at function GetTextRect, offset 0x190, seems to continue to increase.

Dll Versions

C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1\lvrt.dll,    version 7.1.1.4000
C:\WINDOWS\system32\WININET.dll,     version 6.0.2900.2937

Stack for Context Switching lvrt.dell

ntoskrnl.exe!ExReleaseResourceLite+0x206
ntoskrnl.exe!ProbeForWrite+0xbc
ntoskrnl.exe!ZwYieldExecution+0xb78
ntdll.dll!KiFastSystemCallRet
kernel32.dll!Sleep+0xf
lvrt.dll!WSleep+0xd
lvrt.dll!DBAssert+0xb70
lvrt.dll!GetTextRect+0x1b9
kernel32.dll!GetModuleFileNameA+0x1b4

I'm trying to source another machine to test but in the meantime, any  thoughts?

-Chroma

[chromaburst808]

Grrrrrr!!

FIXED.

I followed these links... and hey presto... testexec.exe terminates as normal.

Step Type Problems with TestStand 3.5

Why does TS ask to save 'NI_Database_Types.ini' every time I quite TS?

I think it was more likely the M$ problem than the NI types problem.

Thanks for your patience Terry!

-Chroma

[TerryS]

Hi Chroma,

Glad to hear it's working!  If you ever have any other questions, please feel free to post them on our discussion forums again.

[chromaburst808]

The M$ error is documented here:

Microsoft Tablet PC Platform Component, skchui.dll error

You may experience resource limitations in the Graphics Device Interface (GDI) when you use the Mic...