Why PXI crash when LabView w/DLL downloaded twice?

[Frenk]

Hello,

I have a PXI system running LabView real-time 7.0. My LabView program calls a shared library (DLL) that has been compiled for the real-time system using LabWindows/CVI 7.0.

I can download from WinXP, and run my program without apparent trouble. If I switch back to edit mode, and then back to run mode, and download again, the PXI system reboots, and LabView host on WinXP locks up (on the download progress bar)!

This will happen EVEN IF I DON"T RUN MY CODE. I may download to the PXI, switch to edit mode, make no changes, switch back to run mode, and start a second download to the PXI system. The PXI reboots and LabView in WinXP hangs!

I am in the process of debugging the C-code, so it is not impossible t
hat it does something bad with its pointers. However, if I don't even run the program on the PXI system, why does everything die as described in the paragraph above?

Thanks in advance,
Frenk

[Christian_L]

Hello Frenk,

Could you provide more information about what your DLL is doing and what other DLLs or drivers it is calling. What versions of the different drivers are you using. This problem has been seen with older versions of some drivers, especially NI-VISA. The problem occurs when the drivers is unloaded from memory which happens when you download a new version of your application. You may want to update all the drivers you are using from the NI web site.

Christian L
NI Consulting Services

[JackLF]

If the crash/hang happens just by downloading the DLL the second time then you might start by checking the code in your DllMain's attach code--since that gets called when RT simply loads the DLL during the download. Switching to Edit mode should be unloading the DLL so check the DLL cleanup/detach code for anything that might setup a bad situation as well.

[Frenk]

Hello,

Thank you for your response.

My LabView program sequentially calls a number of functions in my DLL. The DLL is entirely custom code and does not refer to other DLLs or drivers. The purpose of the DLL is to receive some speech data, estimate some parameters that describe the speech, and then return these estimates to LabView.

The DLL has one global pointer to a custom structure that maintains a fading history of estimates between calls to the main calculation function in the DLL. Data is passed to and from the DLL by using pointers to arrays that were initially defined in LabView.

Thanks for letting me know that this behaviour (crash without run) has been observed before with drivers that are unloaded prior to the download of the "new" versi
on of an application. As mentioned above, my DLL does not reference any external DLLs or drivers, but perhaps it has trouble unloading for some reason. I have experimented with much smaller DLLs in the past without trouble (when I was learning how to use them).

Thanks for any further advice.
Best,
Frenk

[Frenk]

Hello,

Forgive my apparent ignorance here... I don't have any explicit C-code in the DLL to handle what you refer to as "attach code" and "cleanup/detach" code.
I thought this was all handled automatically?

I have a number of stand alone functions (none of which are a "main" function). These are called somewhat independently from LabView, but they do share a global DLL pointer to a custom structure within the DLL. An initialization function is called first from LabView to malloc for this global DLL pointer, and at the end of execution it is free'd with another DLL function called from LabView.

Could you briefly explain the purpose of this attach/detach code, and point me towards any documentation (I have looked at the NI document on shared library ca
lls "Using External Code in LabView")?

Sorry for seeming a little clueless on this one. 🙂
Frenk

[Kristi_P]

Hi Frenk,

It's not clear what the problem may be in this case. Can you try stripping out parts of your code until you can pinpoint what's causing the controller to reboot?

Please post a reply if you have further questions.

Regards,

Kristi H
Applications Engineer