TestStand ExitCode -1073740771: what could cause it?

[jarnoe]

Hi all

Anyone, any idea what could cause TestStand ExitCode -1073740771?

Is there any way to debug TestStand Engine and specially its ExitCode?

We execute TestStand sequence (Test UUTs entrypoint) from command prompt and let TestStand Engine return its exit code to %ERRORLEVEL%. The process has worked a long time (almost a year) without problems but now TestStand started to return -1073740771. The same exit code appears apart from sequence pass/fail status.

The problem appeared without any controlled change in the system. The only uncontrolled change could be if Windows has installed some updates. All TestStand and other NI critical updates has been installed. Versions are TestStand Engine Version 2016 F2 (16.0.0.193) 32-bit and Windows 10 Enterprise 64-bit.

That would sound quite simple if behaviour would be same with all sequences but that is not the case. I made a simple sequence including only one numeric limit step. For executing it from command prompt TestStand returns %ERRORLEVEL% 0 when passed and 2 when failed - as expected.

Big thanks for any help in advance!

 /jarnoe

[NIRebecca]

Hey Jarnoe, 

Couldn't see any record of this happening before... although your suggestion of Windows updates may be worth pursuing. 

Exit Status –1073740771 is a Window error equals:

image from: When A Process Does Not Exit Normally 

Are you able to try on another PC and see if the issue follows the code or the PC? Or seeing if anything on the Windows security side is causing this exception. 

[jarnoe]

Hi NIRebecca

Thanks for your reply. It's easy imagine this is not a common issue.

Yes, -1073740771 is not from TestStand but Windows Status - my bad in the original report.

We have several installations of the system. So far we have reproduced the problem on two PCs (both in our test execution environment) and found two other PCs (developer PCs) where the problem do not exist.

I supposed the problem is related with TestStand license type "debug license" but I was wrong. The problem did not follow swapped license types.

I also thought our common windows account causes the problem but I was wrong there too.

The problem exists in two PCs (so far) with a specific TestStand sequence file

• but its not only the seq file as the same seq file does not cause the problem on some other PCs and
• in a PC having the problem I can code a simple TestStand sequence that does not cause the problem
• so it's a combination of PC configuration and our specific sequence file

I can trace and debug the problematic seq file and even its process model (C:\Program Files (x86)\National Instruments\TestStand 2016\Components\Models\TestStandModels\SequentialModel.seq) to the end without run-time errors or any other problems.

Your hint about Windows security if something I've to consider. Do you have any hint what TestStand could try after it ends executing process model? Does it save or check or update something (files, registry etc.)?

Next I'll go through and test every our installation to find out is it really so that problem exists only in our test execution environments and not in development environments.

 /jarnoe

[jarnoe]

Hi again

One idea I forgot to mention... I'm just wondering could TestStand crash be caused if our seq file leaves some handle etc. open... any idea about this?

 /jarno

[jarnoe]

Hi

I've now isolated the problem in our TestStand and LabVIEW side... it's one 3D Plot in one of our system LabVIEW UI. Just loading (having TestStand step calling) a VI including 3D Plot causes problem. Removing the plot from LabVIEW front panel fixes issue.

Above can be demonstrated with files in 3D.zip. Note that problem does not exist in all PCs.

That's is still open what is the problematic difference between PC with and PC without that issue. I'll try to find this out soon. Anyway one difference is there is not MS Office in PCs where issue exists.

'Event Viewer.zip' show entries in Windows Event Viewer after issue happened.

 /jarnoe

[WireWeaver]

This looks like a know issue with LabVIEW:

CAR 238713:

---

---

3D Picture Controls can display transparently or crash LabVIEW on certain graphics cards
The 3D Picture Control is built on a OpenSceneGraph which uses OpenGL. Several reports of the 3D picture control crashing LabVIEW have been reported. In almost all cases it was an Intel integrated graphics card involved. This crash is caused by an incompatibility of the graphics hardware.

Note: Many of the 3D Graphs use the 3D Picture Control

Workaround: There have been several things that have worked for users:

• Update the video driver
• Turn on/off hardware acceleration
• Turn on Aero in Windows 7
• Turn off Aero in Windows 7

---

Hope this helps,

Trent

[jarnoe]

Trent, thanks a lot for the information you share here! Hopefully it lead me to root cause.

I now have workaround for my issue (I removed the 3D Graph). It's now time to concentrate on other tasks as I have spent too much time with this. Anyway I'll get back here when I know what was the change triggering this issue in our test execution environments.

Thanks,

jarnoe