Error 42 in call library function node

[CharlesB64]

Hello,

I encounter an access violation when calling a DLL inside LabVIEW. Let's call the DLL "extcode.dll". I don't have its code, it comes from an external manufacturer.

The code is a simple VI calling a function in the DLL, and prototype is super simple so it cannot be an misconfiguration of the call parameters. The DLL runs perfectly fine when called in other environments (.NET and C).

When I attach LabVIEW in Windbg and run the VI, it stops with the message:

(724.1200): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!RtlNewSecurityObjectWithMultipleInheritance+0x12a:
00000000`76ea527a 8911            mov     dword ptr [rcx],edx ds:ffffffff`b6f27010=????????

And gives the call stack:

ntdll!RtlNewSecurityObjectWithMultipleInheritance+0x12a
ntdll!MD5Final+0xedfc
ntdll!RtlFindClearBitsAndSet+0xdf4
ntdll!RtlFindClearBitsAndSet+0x3a8
ntdll!RtlFindClearBitsAndSet+0x4b9
ntdll!RtlCreateProcessParametersEx+0x829
ntdll!LdrLoadDll+0x9e
KERNELBASE!LoadLibraryExW+0x19c
KERNELBASE!LoadLibraryExA+0x51
LabVIEW!ChangeVINameWrapper+0x36f5
LabVIEW!ChangeVINameWrapper+0x3970
LabVIEW!ExtFuncDynLibWrapper+0x211

Note that dependencies of extcode.dll are loaded before the access violation.

The situation is random, but when it happens all subsequent tries lead to it.

What does it make you think about? Do you think it is a problem in extcode.dll, LabVIEW, or Windows?

PS: I use LabVIEW 2010f2 64 bit, on Windows 7 64 bit (and extcode.dll is 64 bit). I didn't manage to reproduce it on 32 bit system. The error also occurs on LabVIEW 2009.

[Matt_W1]

Since it works in 32bit and in C I'd guess that your using a 32 bit number where you should be using a 64bit one (reading/writing a pointer as an integer). If you can post the C declaration of the function and an example VI with a copy of the call node. I could take a guess on where the problem is.

[CharlesB64]

Prototype is int function(void), so it's not a pointer problem.

Anyway, as you can see this in the stack trace, the access violation occurs during library load, so before the function gets called.

[Matt_W1]

Missed that in the stack trace.

Does it work in 64bit C (maybe the bug is in the 64 bit version of the dll)?

Does this happens every time you call the function or just sometimes?

Do you make anyother calls to the dll?

Have you tried recreating the call library node from scratch?

Just to clarify the error happens when you try to run the CLN, not when you load the VI that contains it, correct?

[CharlesB64]

Does it work in 64bit C (maybe the bug is in the 64 bit version of the dll)?

Yes, when I test it in C it is the same 64 bit version, and compiled into a 64 bit executable

Does this happens every time you call the function or just sometimes?

When it begins to happen, it happens everytime, but it can not happen at all after a reboot for example

Do you make anyother calls to the dll?

Nope

Have you tried recreating the call library node from scratch?

Yes,  I tried to change calling convention, to recreate it via LabVIEW's import DLL wizard or by hand.

Just to clarify the error happens when you try to run the CLN, not when you load the VI that contains it, correct?

Yes it happens when I run the CLN. The CLN is set to "specify library path by node", so the DLL is not loaded until the VI is run. If I set a "static" CLN, the VI is broken saying "not an executable" or something like this. This is because in this case LabVIEW loads the DLL when the VI is loaded, so for me it is the exactly same problem, seen differently by LabVIEW.

[CharlesB64]

---

CharlesB64 a écrit :

Yes it happens when I run the CLN. The CLN is set to "specify library path by node", so the DLL is not loaded until the VI is run. If I set a "static" CLN, the VI is broken saying "not an executable" or something like this. This is because in this case LabVIEW loads the DLL when the VI is loaded, so for me it is the exactly same problem, seen differently by LabVIEW.

---

Update: this is precisely what I set DLL path inside CLN and uncheck "specify path on diagram"

[Matt_W1]

If you fully close LabVIEW (exit out of the getting started window, make sure it's no longer in the process list), and reopen can the problem occur?

Does it work if you run LabVIEW as administrator (I'm not too familiar with the stack trace for dll loading but the one posted looks short, and seems to be failing during security checks)?

If you crash LabVIEW (and leave it opened while crashed), can the c version run?

Can you create a new static CLN after a reboot?

Have you tried the all the combinations of thread and calling conventions?

I had a DLL I wrote just stop working after I updated my daq and vision drivers (removing them didn't fix the problem). I ended up fixing it by recompiling the dll in a newer compiler. I never figured out what the problem was. My guess was that it might have something to do with LabVIEW being IMAGE_FILE_LARGE_ADDRESS_AWARE (which shouldn't affect 64bit in your case), and perhaps the dll as originally wasn't fully compatible with that (I never confirmed that cause since I fixed it).

But since you can't recompile my best suggestion at working around it is to try accessing it indirectly.

Write a wrapper dll in c and try calling that (I suspect this would also break).

Call it through .NET (I'm not familiar enough with .NET to say how to do this).

Compile it into a exe and have LabVIEW interact with it through the System Exec VI.

Write a 32 bit LabVIEW program to call the dll and have that talk to the 64bit one through other means (TCP or maybe server references).