Debugging TestStand System Level Exception Error -17502 with Visual 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.