DLL Hangs LabView

[AIM-USA]

Here is a twist to the problem of a DLL hanging LabView.  Our development group sent me a set of vi's that call C functions from a DLL.  When I try to open the vi's LabView hangs.  I had the vi's changed so the 'Specify path on diagram' was checked.  This resolved the problem of the vi's opening.  Only problem is they wouldn't run when downloaded to PXI target running LabView RT.  Now for the interesting twist.  I kept trying to run the vi's with the 'Specify path on diagram' box checked but I never had any luck getting them to run.  I then went back to original vi's ('Specify path on diagram' not checked) and they would now load and not hang LabView.  On top of that, they downloaded to the target and executed without any problems. 

My question is what could changed in Labview?  I didn't change any options or any parameters in the .ini file.  I am trying to run the same vi's on a second machine and I'm having the DLL hang problem on that machine.  Again, I've compared .ini files and LabView options and there are no differences.  Any ideas?

Thanks!

[rolfk]

---

@AIM-USA wrote:

Here is a twist to the problem of a DLL hanging LabView.  Our development group sent me a set of vi's that call C functions from a DLL.  When I try to open the vi's LabView hangs.  I had the vi's changed so the 'Specify path on diagram' was checked.  This resolved the problem of the vi's opening.  Only problem is they wouldn't run when downloaded to PXI target running LabView RT.  Now for the interesting twist.  I kept trying to run the vi's with the 'Specify path on diagram' box checked but I never had any luck getting them to run.  I then went back to original vi's ('Specify path on diagram' not checked) and they would now load and not hang LabView.  On top of that, they downloaded to the target and executed without any problems. 

My question is what could changed in Labview?  I didn't change any options or any parameters in the .ini file.  I am trying to run the same vi's on a second machine and I'm having the DLL hang problem on that machine.  Again, I've compared .ini files and LabView options and there are no differences.  Any ideas?

Thanks!

---

LabVIEW ini files and options have little to do with such kind of problems. It is most likely something the DLL in question tries to do on loading, that is causing this problem. A possibilitiy is that it is using C runtime libraries that are not present on the target system. If the DLL was compiled with VS 2005 it will almost always reference the mscvr70.dll or similar DLLs unless you go to great lengths when compiling and linking that DLL. Now are these Visual C runtime libraries sometimes standard part of Windows but seldom of a non MS OS like the RT targets are. Also the VS 2005 runtime libraries aren't delivered with Windows XP and older (not sure about Vista) so need to be installed from the Visual C Distributables Installer (but this will likely not work on RT systems since those runtime libraries have again dependencies on (privat and undocumented) functions in the Windows kernel.

Now if it would be just a simple dependency you should get an error when trying to dynamically load that DLL ('Specify path on diagram' checked) or an error box telling you that the DLL in question could not be found (when unchecked). The error is sligthly misleading since the DLL itself could be found but LabVIEW was not able to load it into memory since Windows refused to load it into memory because of missing dependancies.

The fact that loading the DLL does hang LabVIEW makes me guess that the DLL in question does try to do some magic in it's own loading function (DLL_PROCESS_ATTACH) and hangs in there because of missing Windows components or something.

This goes deep into Windows internals and without seeing the source code of the DLL in question it is almost impossible to give more detailed advice.

Rolf Kalbermatter

[zio]

I have a strange problem with a dll call that seems to hang some vi's, but not all, and exits with a Win32 API error 214 or 215.

I am using an executable built with LV 6.1, running on WinXP, multithreading disabled, but dll calls set to reentrant, because two reentrant modules call the same dll (a Galil ethernet motion control board). The dll calls are used to send commands to the board, through a TCP-IP network. The commands are immediate (set variables and read response).

Almost all the modules are set to run on the "same as caller" thread, exept some low level I/O modules.
Most modules (about 15 out of 18) hung for 150 seconds (160 another time), including the Process Controller and the User Interface, but one module that uses TCP-IP, on the same "same as caller" thread, continued to run, using most of the CPU.
This has happened a couple of times in the last months, and is not really reproducible, but happened twice in the same day a couple of days ago, and has become a concern.

In my experience, with multithreading disabled, a call to a dll (or ActiveX) will hang all vi's on the same LV thread, because somehow, LV passes control to OS and waits for the call to finish. Maybe this is not true for reentrant calls. Or maybe this is not apparent with a dual core (or hyperthreaded) processor, as in our case.

Microsofts explanation of the errors is:

ERROR_TOO_MANY_MODULES  214  0xD6

Too many dynamic-link modules are attached to this program or dynamic-link module.

ERROR_NESTING_NOT_ALLOWED 215 0xD7

Cannot nest calls to LoadModule.

I cannot make out which of the parallel modules is hanging the others, or why, and why some modules are not hanging.
Any suggestions?

[Karunya_R]

Hi Zio,

What low level I/O modules are you using? Have you had the problem since? This might be useful for you.

[MScap]

Hi

I am facing a similar problem.

I made a LV vi. I created the DLL for it. The vi runs perfectly, using a PXI card.
The DLL, if called in another LV vi, hangs LV.

I am not conencting any PXI when using the DLL. I am just giving inputs from LV controls.
the moment i click run, LV hangs.


I am not able to understand the problem. It could possibly be that the data is not read by the DLL.

Note: the DLL was made using Build specifications of LV 8.2.1
          the DLL was set to be reentrant

[MScap]

Hi

I am facing a similar problem.

I made a LV vi. I created the DLL for it. The vi runs perfectly, using a PXI card.
The DLL, if called in another LV vi, hangs LV.

I am not conencting any PXI when using the DLL. I am just giving inputs from LV controls.
the moment i click run, LV hangs.


I am not able to understand the problem. It could possibly be that the data is not read by the DLL.

Note: the DLL was made using Build specifications of LV 8.2.1
          the DLL was set to be reentrant


I am attaching a screenshot of the actual vi. It generates a waveform based on the specifications read and stops once the number of cycles are generated. I have used only numeric and string I/O.
This vi runs fine. The DLL,also attached, is hanging.


Someone, please help me! I had already spent 5 days on this.

[Dennis_Knutson]

Attaching an image of the front panel and the dll does not help very much. Could you attach the VI? Need to see how you are stopping the loop.

[Jim_M]

Hi MScap,

      I've read your problem description from your other thread here.  I want to clarify something.  You say that you have set your DLL as reentrant, so that you may call multiple instances of it and are trying to use one call to the DLL to run the code and the other call to the DLL to abort the original DLL.  If this is the case, the reason the abort function will not work for the original DLL call is because you are opening up a separate instance of the DLL.  There would be no communication between the DLL calls and therefore the abort is just aborting the second instance of your call and not impacting the original DLL call which is probably hanging for some reason.  Have you tried building a stop into the VI so that it will stop after 100 interations of your loop or some finite maximum number?  This will guarantee that your DLL call stops after some period of time.  Please feel free to reply if I have misunderstood your application.

[MScap]

Hi


Thanks for the reply.

I am nto sure I can attach my actual vi here. Let me try to explain.

The use a Global vi, that reads/writes into a 'stop' cotnrol. This global vi output/an error in the loop stops my generation.

So, the first instance of the DLL should be generating the waveform. The second instance shall write 'true' into the Stop cotnrol.

In this case my 'stop' is a numeric. So, we shall write any value > 0 into it.

Irrespective of the stop control being present, the loop should terminate under two conditions:

1. when the defined number of cycles of the waveform are generated.
2. when there is an error in the loop.

As these two conditions are not dependant on my using a reentrant DLL, or a separate instance, the VI must stop on either of the above mentioned two conditions.

I hope i made the point clear.

Forgetting the 'stop' control, the vi is hanging!!

For further understanding, i am attaching a sample vi, made using the same concept. This is running fine. The problem is occouring only in 'generation' vi and not in any other vi using the same concept.



Thanks

[MScap]

I also have a doubt.

When i tried to build the DLL, it showed an error that certain dependencies are not found.

I use LV 8.2.1. I located the required vis from LV 8.0,loaded them and saved the project. The build was then successful.

In the same project, the DLL for another vi (performing swept-sine analysis) is giving the same error(of dependencies not found).


Is this problem of hanging related in any way to the "dependencies not found" error?

I found the required files in LV 8.0 and used them. Can this be a reason?

I installed the requried toolkits(simulation toolkit) and am still not having the required vis in LV 8.2.1. So, i am loading them from LV 8.0.

Every time i try to build the DLL, it gives me this error.

I am a fresher to LabVIEW. So, if you find my quiries or problems silly, dont mind!