VI server concept for calling dlls

[Lycangeek]

Just to make sure we are on the same page, here are some things to note about what you sent me...

1. The example on my blog uses LVDLLStatus() as the function to call before pump messages - that is the function to call, not the Add that you defined. It is a special entry point into LV to help get everything set up before you call.

2. I am assuming that ADD is the method exported from your LV DLL. Just to make sure...
a. Both LVDLLStatus and PumpMessages are defined as cdecl, not stdcall. Your ADD method may well be exported as stdcall - it depends how you set up the Application Builder. Just want to make sure it isn't a simple mistake.

3. Make sure that the call to LVDLLStatus and PumpMessage is done only in global.aspx.cs file. This isn't something you call in each web page.

4. If the C DLL provided by your client is sometimes hanging, the number of possible reasons is staggering. The things I would check to start with are
a. That the PInvoke (DLLImport statement) is correct. Double check the cdecl/stdcall, ANSI/Unicode, etc. Be very careful here.
b. See what dependencies this C DLL has. For example, does it try to pull in MFC or some other set of DLLs. This is often a major pain point because MFC has its own set of problems in this case.
c. Check the memory allocation expectations. Do you ever allocate memory and have the DLL free it, or the other way around? If so, chances are that the heaps are not lining up and you are getting memory corruption.
d. When the system hangs, is it deadlocks or spinning - this is a quick check - does the CPU jump up or sit near zero.

I really don't know that I'll be able to help much besides calling in suggestions from the shore. After all, the code being called could well be the problem. For example, is the user DLL multi-threaded safe? ASP.NET can result in more than one thread calling the user's DLL and if it isn't prepared for that, you can get into serious problems.

[HCL Tech]

Hi,
Since I was facing problem in LabVIEW DLL. I created a simple LabIVEW DLL (Add.dll)
The .h file of the same is as below:-
________________________________________________________________________
#include "extcode.h"
#pragma pack(push)
#pragma pack(1)

#ifdef __cplusplus
extern "C" {
#endif

void __stdcall ADD(double Numeric1, double Numeric2, double *xY);

long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);

#ifdef __cplusplus
} // extern "C"
#endif

#pragma pack(pop)
___________________________________________________________________________
From the above the add.dll is a __Stdcall.

I will replace add.dll with LVDLLStatus and try it out.

I am calling the PumpMessages only in "global.asax" page. I don't have any page like global.aspx.cs.

Regarding 'C' DLL I will check what all you told, and mail you once again.
Thanks,
Poornima

[HCL Tech]

Hi,
I replaced add.dll with LVDLLStatus in global.asax file.
Even then I am facing the ASP.NET code hang problem with 'C' DLL and not with LabVIEW DLL.
Initially before adding LVDLLStatus and PumpMessages in global.asax file, if more than one aspx page is opened, it was hanging at LabIVEW DLL call, so you gave me the solution to modify global.asax file. After this modification, ASP.NET code was working fine with LabVIEW DLLS, but not with 'C' DLLs.
With one aspx page, ASP.NET code is working fine for both LabVIEW and C dlls, but with 2 or more aspx pages, ASP.NET code hangs at 'C' DLL call inconsistently.
Is it required for me to add some 'C' dll like LVDLLStatus in global.asax file?
Actually .NET code is not hanged, it will waiting for the DLL to return the output parameter.
Thanks,
Poornima

[Lycangeek]

The fix I gave you was specifically for a LV issue when using LV DLLs. It isn't going to do anything for non-LV code.

What it sounds like is that the C DLLs you were given are not multi-threaded safe. I can't say for certain, but it is a good guess. What I would recommend doing is to create a .NET wrapper class around the DLL (thus the call to the DllImport function is done from within a class). Then create a static private member of type object. This is what you would create for a lock. For example, assuming you defined your DllImport method Foo()...

using System;
public class FooWrapper
{
private static object m_lock = new object();

public static void CallFoo()
{
lock(m_lock)
{
Foo();
}
}
}

Make sure ALL methods for this DLL then go through this wrapper class, all using this lock. This would at least ensure that only one ASP.NET thread is calling your DLL at a time. (There are exceptions when running under Windows 2003 where it can create multiple AppDomains for the same Web Application, but I think you have to specify that...).

The best solution is to make the C DLL MT safe by putting the locks inside the C code. That will make it safe in all cases.

[HCL Tech]

Hi,
Thanks for your reply.
Since I am facing the same problem, what I faced with LabVIEW DLL calls, I thought you can help me to solve this.
Even though multiple aspx pages are opened, I am not calling LabVIEW or C DLLs in all pages.
Say For Example, I have Main page called "test.aspx". On the front end of this page I have a button called "Run Test". On click of this button, public functions defined in a module say "Testcases" module is called, which in turn call LabVIEW and C DLL calls. In the same page (test.aspx), I have one more button called "View Results". On click of "View Results" a separate aspx page called "Results.aspx" will be opened, which display the test results taking it from MS access database in some defined format.
If I don't click on "View Results" button, the ASP.NET code works fine. If I click on this button, when it opens another aspx page (Results.aspx), the ASP.NET hangs at DLL call. (Before it was hanging at LabVIEW DLL call, but after modifying the code in global.asax page, it hangs at 'C' DLL call)
I deleted the code used to diplay test results in results.aspx page, just to verify whether the database is not causing problem. In "Results.aspx", I did not have any code, except page refresh. Even then the ASP.NET code hangs at DLL call.
(According to the requirement multiple Aspx pages needs to be opened. Here just for understanding I have mentioned two. I need to implement Master-Slave concept for the ASP.NET software. Like first screen will be login screen, as soon as first user logs in, he becomes master, that is complete GUI will be enabled to him. He can conduct the tests using Test equipment, which in turn call DLL calls. If another user log in to the software, he will be slave mode. Complete GUI will be disabled to him. He can view only the test results of the tests conducted by master. Here I started facing LAbVIEW DLL call problem. So, just to make sure of the DLLs, I am working on sample code as explained above.)
Please help me to sort this issue.
Thanks,
Poornima

[Lycangeek]

I'm not sure that I'm going to be a lot of help - but I am confused by what you said. It sounded like the test.aspx is what had the LabVIEW and C DLLs. The Results.aspx was just calling out to a database. I assume that the database calls are ADO.NET talking to the db. So, where is the C DLL being called in Results.aspx? Also, what exactly is this other C DLL doing?

[HCL Tech]

Hi,
Sorry to confuse you.
I have two aspx pages
1. Tests.aspx
2. Results.aspx

I am calling all the dlls from tests.aspx page, and in results.aspx page I am not calling any dlls, just refresing the results.aspx page.
When the DLLs are getting executed in Tests.aspx page, at that time if Results.aspx page is opened, the complete ASP.NET software stops executing, waiting for the DLL to return, but which never happens.
From tests.aspx page there will be a call to DLL, and it will enter DLL, but never comes out of that, if results.aspx page is opened.
If Results.aspx page is not opened, then all the DLLs work fine. I know this problem is due to ASP.NET, may be due to some ports. For this you gave solution to modify global.asax page, which I did and LabVIEW DLLs started working and 'C' DLL call are not working.
If you can't help me much in this, that's OK.
Anyway thanks for your kind co-operation.
With Regards,
Poornima V

[RamN]

Hi:

Your discussion thread(and Brian) seems to match with what I am currently doing with an ASP.NET application.

Was your ASP.NET Calling LabView DLL sucessfull. Brian's theory seem to work but I am not sure whether it is a memory issue or calling a LabView Dll is fundamentally wrong.

In short the application stalls and I have to explicitly kill the process.

Do you have a step by step process to explain or share with.

Thanks

Ram.

[Lycangeek]

Not sure what exactly you want to know. If you check out http://detritus.blogs.com/lycangeek/2005/05/labview_and_asp.html, I go into detail on what is going on. The basic problem has to do with Windows message pumping and assumptions LV makes about the client code.

Now that LabVIEW 8.0 is announced, I'll point out again that this has been fixed in 8 - LV now creates its own thread for its messages and so none of this is required. But for LV 7, just creating the thread and pumping messages as I've shown should fix the hang.

[HCL Tech]

Hi Ram,  DLL calling problem in ASP.NET is not yet solved. In ASP.NET application I am using LAbVIEW DLLs and C DLLs. Brain gave me the solution for LabVIEW DLLs, but for C DLLs I don't  have any solution right now. In the Main GUI of ASP.NET I have Run Test button. On click of this button, in the backend code, some of the LabVIEW DLLs and C DLLs will be called. The result from the DLLs will be tested and stored in an Access Database. In the Main GUI of ASP.NET I have one more button "View Results". On Click of this, a separate webpage (Results page) will be opened. In the backend code of this results webpage, I will take the results from the access database and display it in a grid. I am facing problem here. With only one webpage my LabVIEW and C Dlls work fine. On click of results button, when opening results webpage,  the C Dlls will not work. If you have solution for this, please let me know. Thanks, Poornima