Can't step into CVI step that calls LabVIEW DLL?

[Joe Roberts]

Windows 2000 SP1
TestStand 2.01f
LabWindows CVI 6.0
LabVIEW 6.1 Runtime

We have a framework based on TestStand and CVI. A customer has supplied us
with a DLL written in LabVIEW 6.1 and packaged with the Application Builder
that we need to call from a CVI test library DLL. They say they can't
supply us with a non-LabVIEW implementation. We installed the LabVIEW 6.1
run-time. We added code to the CVI test library to dynamically load and
unload the LabVIEW DLL using LoadLibrary and FreeLibrary. LoadLibrary is
called in a function in the MainSequence Startup step group, FreeLibrary is
called in a function in the MainSequence Cleanup step group.

Things run as expected when the CVI DLL is built as Release or Debug and the
CVI
adapter is configured to run in-process.

However, if we try to debug CVI DLL by building it as Debug and configuring
the CVI adapter to run in an external instance of CVI, things hang the first
time we try to step into, or run, a CVI test library step that calls one of
the functions in the LabVIEW DLL. On the Applications tab in Task Manager,
the item named LabVIEW is marked as 'Not Responding'. The only way to
recover is to kill the LabVIEW process, which takes down CVI and TestStand
with it. If none of the LabVIEW DLL functions are called, no problems are
seen (no hang).

I assume the problem has something to do with the library getting mapped to
the wrong process space (TestStand v. the external CVI instance). Is there
any way to solve this problem? Any ideas or suggestions would be
appreciated.

---
Joe

[Elaine_R.]

hello Joe -


Out of curiousity, what happens if you attempt to debug your DLL from CVI? For example, configure TestStand to run its steps 'inProcess'... but then close the TestStand application and in CVI, configure it so that the Specified External Process dialog points to TestStand's SeqEdit.exe (CVI launches TestStand when debugging the project). Once TestStand is running, run your test and set your break points as usual, you should be able to step into the CVI code if nothing else. If not, I would be interested in hearing what problems you encounter.

The nice thing about debugging directly from Labwindows/CVI while TestStand runs 'inprocess' is that you can avoid some library linking errors, which may be the source of the troubles you are seeing.

-
-Regards

Elaine R.
National Instruments
http://www.ni.com/support

[Joe Roberts]

> Out of curiousity, what happens if you attempt to debug your DLL from
> CVI? For example, configure TestStand to run its steps 'inProcess'...
> but then close the TestStand application and in CVI, configure it so
> that the Specified External Process dialog points to TestStand's
> SeqEdit.exe (CVI launches TestStand when debugging the project). Once
> TestStand is running, run your test and set your break points as
> usual, you should be able to step into the CVI code if nothing else.
> If not, I would be interested in hearing what problems you encounter.

When 'debugging' SeqEdit from CVI, we experienced no lock up.

Thanks for this suggestion. Debugging from CVI is a workaround for now,
though not highly desirable as it is reverse from normal debug proc
edure
(user can't step into CVI from TestStand). Still would like to know if
'normal' debugging of this problem is possible.

> The nice thing about debugging directly from Labwindows/CVI while
> TestStand runs 'inprocess' is that you can avoid some library linking
> errors, which may be the source of the troubles you are seeing.

The problem appears to be general to LabVIEW DLLs called from an external
instance of CVI under TestStand. We were able to reproduce the problem with
a simple LabVIEW VI compiled to a DLL, then called from a simple CVI DLL
under TestStand. We will package up some sample code and submit it to NI
tonight or tomorrow.

Thanks for you help.

---
Joe

[Elaine_R.]

Hello Joe -

When debugging CVI DLLs (or any DLLs) we usually do recommend the process I described above. It is also addressed in KnowlegeBase 268E2NBD. While I agree that it is a reverse of customary behavior, it really is the most reliable method for stepping into any c/c++ style DLL (CVI or otherwise). Thankyou for forwarding your code to our support email, someone will attempt to reply to you soon.

--Regards,

Elaine R.
National Instruments
http://www.ni.com/support