Debugging TestStand System Level Exception Error -17502 with Visual C++

Updated Sep 28, 2024

Reported In

Software

  • TestStand

Programming Language

  • C++

Issue Details

When a code module called by TestStand does not handle a system exception and it completes its execution, TestStand generates error -17502. How can I find what is throwing the error?

Solution

The following technique loads the main Executable of the process (in TestStand's case, either the Sequence Editor or the Operator Interface executable) and using the Visual C++ debugger, you can find out which DLL is causing the problem. This method will be most useful if you have your load options of your sequence and/or steps is set to "Load Dynamically" for the sequence that is causing the problem. 

Follow the below steps to debug:
  1. Launch Visual C++.
  2. Select File » Open Workspace.
  3. Change "Files of Type" to "Executable Files". 
  4. Open TestStand\bin\SeqEdit.exe
  5. Select Build » Start Debug » Go
  6. Once the sequence editor is launched, select Debug » Exceptions.
  7. In the Exceptions dialog, select "All types of exceptions" and select "Stop if Not Handled".
  8. Visual C++ will catch all exceptions. Many first chance exceptions will get thrown, but most of these will be handled. Don't be alarmed, because this is normal. If first chance exceptions are not handled by any other code, then TestStand handles them and displays the -17502 error (instead of crashing).

Additional Information

Error -17502 is an operating system exception being passed back to TestStand, which then reports it to the user. The operation the user performed is throwing error -17502, which can have different causes. Some common causes are:
  • Writing to memory which you do not have access to in your code
  • Exceeding array bounds in your code
  • Dividing by Zero in your code
  • Passing the wrong input parameters to DLL function call
Note:
-This KnowledgeBase entry shows you how to find out which DLL is throwing the exception. If you know the DLL that is causing the problem, then you should step into the DLL code and find out why and where the exception is being thrown. 

-This technique will only work if the code modules are running in-process. It will not work if you are using LabVIEW code modules or CVI code modules that are configured to run in an external process. The Visual C++ debugger can only track within one process at a time.

Other Support Options

Ask the NI Community

Collaborate with other users in our discussion forums



Request Support from an Engineer

A valid service agreement or active software subscription may be required, and support options vary by country.