Process Hanging when using LabVIEW Shared dll on IIS 6.0 with Multiple Processors

[jprucha]

Hi All,

We have come across an issue with a LabVIEW shared dll that we have built to be used with a .Net application. The dll was built using LabVIEW 7.1 and we are using a Windows 2003 server with IIS 6.0 and dual xeon processors. The shared dll when calling the exposed function will work the first time through, but when successive calls are made it will no longer work(meaning the aspx page will hang). The hanging takes place somewhere in the LabVIEW code. When we have tried this on a sandbox environment which is a single processor machine the application works without failing over and over again.

Does anyone have any ideas why a LabVIEW shared dll will not work on a multiple processor machine? Maybe a possible solution? We are able to set the affinity on the web server with our application running in its own application pool but the IS department does not want to do this on the staging and production systems.

Just a bit of background on the LabVIEW application. The exposed function takes in a string (XML) and returns a string (XML). Once the XML is received and parsed a series of function are performed on the data sent to it. Once finished with the functions it will send the output data to two waveform graphs that we take a snapshot of and save to the file system. The output XML is now formed and sent back to the .Net application and is then displayed to the user in the aspx page.

If anyone has any thoughts or suggestions I would be glad to hear them.

Thanks in advance,

Jim

[Lycangeek]

Jim,

I am not sure what problem you are running into but here are some things to check...

1. Does this happen with a load test or heavy user load, or can you reproduce it with no load on the web server and just hitting the page via a single browser? Not sure what kind of control you have on the production server.

2. Especially if you can isolate the problem as described above, you can try out the CLR Profiler from Microsoft. This may at least give you an indication of where you are hanging. I've got some handy links for the profiler on my blog (http://detritus.blogs.com/lycangeek/2005/02/clr_profiler.html).

Brian

[jprucha]

Hi Brian,

The problem that we are actually running into is that the first time we go to the aspx page and enter the XML for the application and click a button to perform the code behind which the code behind calls a LabVIEW shared dll and returns XML that we display to the client on the aspx page it works fine. If we call the aspx page a second or subsequent time the aspx page will hang on the call in the code behind to the exposed method in the shared dll.

This is happening with a very light load, 1 user. We need to get past this to test with a multitude of users. 🙂

As far as using the CLR Profiler I'm kind of in a bind here as I don't have physical access to the box. I can move applications over, change web.config and that's about it.

One thing you should know is we have opened a ticket with Microsoft and they inspected the dump upon the hang of the aspx page on the second trip and have found that the LabVIEW runtime (lvrt.dll) is callling its function ThMutexDestroy, and that goes into a waiting state during the hang. Of course Microsoft has asked us to have National look into this.


Jim

[Lycangeek]

Ouch - that is not a lot of access to the machine. Very strange that this is happening only on an SMP box even when having a single user.

I would recommend that you go ahead and open that ticket with NI so that we can take a look at the dump and see from where the ThMutexDestroy is being called from. Let me know the ticket number when you get it and I'll follow up with the AE. You can email it to me via my blog contact if you want.

Also, how complex is this? I was wondering whether we would be able to try to reproduce it in house.

Brian