error 998 when calling dll

[Ulli27]

Hello,

I'm using LabView9 32-bit on 64-bit machine (Windows7) and I'm trying to call some functions from an external dll (32-bit).

When configuring the call-library-function-node to use this dll I get an error message saying:

 "error loading (filename of dll)". Invalid access to memory location.

The message is in German as is my operating system.

Now I wrote a little test app in VC++ which directly called the dll. Everything worked fine.

Next I wrote a wrapper-dll to call the original dll's functions and used that with my test app in VC++. Also no problems.

Finally I configured LabView to call the wrapper-dll and got no error message at least right after configuration.

But when I run the VI and debug the wrapper-dll I get an error 998 when the wrapper-dll tries to load the original dll.

According to Microsoft's description of system error codes this is ERROR_NOACCESS and means exactly "Invalid access to memory location".

So for some strange reason LabView isn't able to load that dll, which is obviously no problem for a C++ app.

Any help on this would be very much appreciated since my project is strongly dependent on getting this to work.

Best regards,

\Ulli.

[TomAD]

Check out this page.

-Tom

[muks]

Also see this

[Ulli27]

Thank you for your tips.

However the Microsoft article I already knew, but so far it's not really useful because I don't have access to the source code of the dll.

I wonder why - if it's a MS related problem - the loading of the dll fails always and only when I call the LoadLibrary function from within LabView, even through a VC++ wrapper!?

Btw. this is what the debug output says when I inspect the wrapper code (alpD41.dll is the dll I actually want to access):

'LabVIEW.exe': Loaded 'D:\install\Vialux-DMD-32-bit\ALP-4.1 high-speed API\alpD41.dll'
First-chance exception at 0x126200bb in LabVIEW.exe: 0xC0000005: Access violation reading location 0x7306b12e.

Regards,

\Ulli.

[Believer]

Ulli,

Did you get this resolved? If so could you post the solution?

Thanks,

Ronnie

[Ulli27]

Hi Ronnie,

unfortunately there is no direct solution for this issue so far. Both sides, the dll-vendor (texas instruments) and ni are aware of it, with ni (in my opinion) at least trying to solve it.

The cause seems to be some encryption stuff on the vendor side (they use an usb dongle). Is something similar involved with your problem?

My current workaround is to have an external wrapper app written in c++ accessing the said dll. To this wrapper I communicate via socket to realise the function calls.

This is quite annoying since it's a bit of work to do and you definitely loose performance. But so far no one was able (and in case of Texas Instruments even not willing) to help on that problem.

And again: for me this issue applies only for the said configuration:

Windows7, 64-bit,

LV2009, 32-bit (I cannot use 64 bit because of some 32-bit-only toolboxes)

the dll is available both in 32 and 64 bit...

I'm still exited, if there will be an official solution,

good luck,

\Ulli.