CVI crashes when calling function from external DLL

[Phlamb]

I'm calling a CVI library from Test Stand 4.1.  In that CVI library I load an external DLL (using LoadLibrary) and create a few function pointers (using GetProcAddress).  The DLL loads successfully, and I get addresses for all of the imported functions.  

However, when I one of the functions is called CVI crashes (Test Stand says it lost the ActiveX connection to CVI) when executing in an external CVI instance.  If executed in the Test Stand process I get a system level exception.

If I step through the code in CVI, it hangs after trying to step into or over the call to the function pointer from the external DLL.

I am able to call the functions in a small test project I created in CVI, however when integrating it into an existing test library and calling it through Test Stand it fails.

Any ideas on how to go about debugging this issue?

[Jensen W]

Can I get some clarification on what the last two statments mean?  When you say you step through the code in CVI, is this while it is still called from TestStand, or are you debugging straight from CVI?  When you say you are able to call the functions in a test project you created in CVI, does that mean you created a small project calling simple DLLs from CVI , and called it from TestStand, or you tried calling the same DLLs that are causing problems in a project from CVI without TestStand and that works?

[Phlamb]

Sorry for the confusion, I'll try to clarify:

When execution hangs when stepping through the code in CVI it is being executed from test stand, using the external CVI adapter.

I tried calling the same DLLs from a CVI project built as an .exe and run without test stand, and that works correctly.

[Jensen W]

How is your adapter configured?  If you open TestStand and go to Configure>>Adapters...  The Adapter Configuration dialog box will appear.  Highlight LabWindows/CVI and click Configure... Then inside the LabWindows/CVI Adapter Configuration dialog box in the Step Execution section, try selecting the Execute Steps in an External Instance of CVI.  Let me know if this is already selected, or if after using the option the problem is still present.

[Phlamb]

I've tried with the adapter configured to execute both in-process and in an external instance of CVI.  When executed in an external instance I get the following error when one of the functions from my external DLL is called:

Lost ActiveX connection to CVI. The CVI adapter will attempt to reconnect on next execution.

-17702; An error occurred accessing the CVI ActiveX automation server.

[Jensen W]

What happens when in-process is selected?

[Phlamb]

If executed in process I get the error:

No details available.

-17502; System Level Exception.

[Jensen W]

Have you tried calling into the dll that CVI calls directly from TestStand?  I am curious to know if this also crashes.

I am also curious to know if there are any path references in the dll that is called by the CVI program.  If so are they relative, or absolute paths?

I ask because one of the possibilities is that relative paths are being used to specify a path from the location of the code that is called, and they are not working because the current working directory is being specified by TestStand, and the paths are not relative to the working directory given by TestStand.

[Phlamb]

When calling the .dll directly from test stand I get the same error:

-17502; System Level Exception.

No details available.

All of the other .dlls that this one depends on are in the system path, and the library doesn't access any files by relative path.

[Jensen W]

Do you have the ability to debug the dll that is being called? If so, I would suggest running a debug session to pinpoint where the crash happens when it is called from TestStand.  If you don't have the ability to debug, but can get access to the source code it would be worth looking in the dll to ensure that it doesn't try to access anything using a relative path.

If none of the above are options, you can try to attach to the teststand process and try to catch a first chance exception.  That may give us some more useful information.