LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CVI crashes when calling function from external DLL

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?

0 Kudos
Message 1 of 10
(4,272 Views)

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?

Jensen
National Instruments
Applications Engineer
0 Kudos
Message 2 of 10
(4,250 Views)

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.

 

 

0 Kudos
Message 3 of 10
(4,225 Views)

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.

Jensen
National Instruments
Applications Engineer
0 Kudos
Message 4 of 10
(4,220 Views)

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.

0 Kudos
Message 5 of 10
(4,217 Views)

What happens when in-process is selected?

Jensen
National Instruments
Applications Engineer
0 Kudos
Message 6 of 10
(4,211 Views)

If executed in process I get the error:

 

No details available.

-17502; System Level Exception.

0 Kudos
Message 7 of 10
(4,207 Views)

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.

Jensen
National Instruments
Applications Engineer
0 Kudos
Message 8 of 10
(4,181 Views)

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.

0 Kudos
Message 9 of 10
(4,132 Views)

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.

Jensen
National Instruments
Applications Engineer
0 Kudos
Message 10 of 10
(4,120 Views)