Message Popup crashes TestStand

[JCX]

Hello,
Our sequence executes under TestStand 3.5 ; steps call dlls written with LabWindows/CVI 7.1.1.
Everything is going fine except some calls to the "Message Popup" step of TestStand : sometimes TestStand crashes on such calls (we have to stop it from Windows Task Manager). We have several "Message Popup" to display during the sequence execution and we have noticed that the application does not systematically crash on the same Message Popup step.
The target computer is a PIV 3.2 HT with 1Gb RAM.

Does anybody have the same problem ?

[AllenP]

I'm guessing you only see this problem when using the CVI Operator Interface?  If this is the case, try upgrading your CVI Runtime Engine to 8.0.  There is a thread safety issue with older versions of the Runtime engine that occurs when using CVI Applications with ActiveX controls that then try to create popup panels.  Upgrading to the CVI 8.0 Runtime Engine should fix the problem.  You can download it for free on NI's Drivers and Updates page.  You will can still use it with applications and dlls created in older versions as CVI as well.

Allen P.

NI

[JCX]

Hello Allen,
Well actually we don't use the Operator Interface, the crash occurs when using SeqEdit.
We will try to install CVI 8.0 runtime and I will tell you if crashes still occur.

[JCX]

Hi,
We have installed CVI8.0.0.273 runtime engine and we still have crashes on some Message Popups in SeqEdit.

Here is a short description of the system : we have a PXI 1000B chassis connected to the computer with a PCI and a PXI MXI-3 (software v1.15). 
PXI cards : 2 PXI CAN 8461/2 (one dedicated to DiagOnCAN and the other one for CAN), 1 PXI 6070E, 1 PXI 6713, 1 PXI 6704, 1 PXI GPIB. We also have 2 PCI cards : Addi-Data APCI 2032 which drive the relays of the system. We have installed DAQ-mx 8.0 (DAQ 7.4.0 is also used on the system for an other application, not with TestStand), NI-488.2 2.43 and NI-CAN 2.3.2.
Our application is multithreaded (3 threads + 1 main thread).

We have tried several solutions not to use the step "MessagePopup" of TestStand : we have created a specific step calling a CVI dll. In this dll we call the CVI MessagePopup function, but TestStand still crashes. Next we have tried to display a panel (created in a uir file) instead of the Popup but the problem is not solved (we tried several combinations of panel attributes).
In Windows TaskManager we see that the PIV 3.2GHz HT is never overloaded (CPU load = about 90%) and that there is enough memory available on the system.

If we try to run a sequence that creates 3 threads which process nothing (infinite loops), with no signals / CAN / instruments processing, we can't reproduce the crash caused by the  Popups.

Do you have any suggestion about that ?

[AllenP]

Are you calling other code modules in your sequence?  You may want to turn on some of the Debug Warnings on, to see if one of your other steps is causing the crash.

You can turn them on in Station Options >> Preferences >> Debug Options.  This may help identify if another code module is doing something improperly.

If you are not calling any other code, I would be interested in seeing the simplest case that reproduces this problem.

Allen P.

NI

[JCX]

Hi,

The only code modules we call in our sequence are our dlls developped with LabWindowsCVI. Some of those dlls also call low-level dlls.
All the Debug Warnings are turned on, and we have none of them that appear.
Unfortunately we tried to reproduce the bug without our test bench but we could not.

Maybe something interesting : we have a test Sequence wich calls all of our steps. The steps' parameters are always different in order to validate the whole bench (all the sensors and all the actuators) : the sequence is written that way : one of our steps, one MessagePopup, one of our steps, one MessagePopup, and so on.
If the bug appears in this sequence, we have to kill TestStand from Windows TaskManager and relaunch it. If we relaunch the sequence, the bug systematically reappears after the same step. If we skip several steps, the bug appears lower in the sequence.
We do have checked memory allocation in our dlls : no leakage. And no leakage at high levels (memory allocated in TestStand).