using code interface node with dll crashes LV 2011 but not LV 8.6... using max error handling does nothing

[MarkCG]

Hi all,

I'm having a peculiar problem.

I inherited a project saved in LabVIEW 8.6. The project must use of particular dll that was built a few years ago. The original developer and source code for this .dll are long gone. The very core logic exists, in the form of embedded C code, and that's it. The .dll is called through a Code Interface Node in LV 8.6 and this setup manages to "work". Howver, running the VI that calls this .dll in LV 2011 causes an "insta crash", as in, no "program has stopped responding".  Error message pops up, then all LV windows close.

It's very similar to that described in here:

http://digital.ni.com/public.nsf/allkb/D84C9775ABD921CF8625772A005CA50C

but this KB says to try putting the amount of error handling to maximum. I tried that, but it didn't help. 

Using the "Debug" option allows me to run the just-in-time debugger with CVI 2010, which then proceeds to say this:

Finally, I manage to get this out of it: 

FATAL RUN-TIME ERROR:   Unknown source position, thread id 0x000012D4:   A non-debuggable thread caused a 'General Protection' fault at address 0x00000000.

I don't think that really helps at all, but it's there.

Here is the function prototype of the .dll:

void  _inputPM@224(uint8_t arg1, uint16_t arg2, uint8_t arg3, float arg4, float arg5, float arg6, float arg7, float arg8, float arg9, float arg10, float arg11, float arg12, float arg13, float arg14, float arg15, float arg16, float arg17, uint16_t arg18, uint16_t arg19, uint16_t arg20, uint16_t arg21, uint16_t arg22, uint16_t arg23, uint16_t arg24, uint16_t arg25, uint16_t arg26, float arg27, float arg28, float arg29, float arg30, float arg31, float arg32, float arg33, float arg34, float arg35, float arg36, float arg37, float arg38, float arg39, float arg40, float arg41, float arg42, float arg43, float arg44, float arg45, float arg46, float arg47, uint16_t arg48, uint16_t arg49, uint16_t arg50, uint16_t arg51, uint16_t arg52, float arg53, float arg54, float arg55, float arg56);

(never seen a function take 50 input params like that (wouldn't you use a struct? array? something? But I digress, and I don't know anything about .dlls...))  

I do have a ".lib" and a ".cdb" file with the same name as the .dll, but those also looks like some kind of compiled file. 

I'm sure the answer I'm going to get is that there is no way of telling what's really going on without .dll source code. I'm hoping against hope that there may be another way or hack.

Any ideas? Thank you for you help. 

Regards,

Mark G 

[JÞB]

you will need to atone for your CIN's.  (Convert them to Call Library Function nodes.)  CINs have been demoted since 8.6

[MarkCG]

My bad... I meant to say call library function nodes. I checked and that's what they are. 

[myle00 · Accepted solution]

I'd play around with the calling convention and see if that helps, i.e. try both the c and stdcall convention since maybe you're importing it incorrectly in LabVIEW.

I don't know if you have access to visual studio or some such program, but you might try to call the dll from c/c++ and see if you have this issue.

Are you using a different operating system (i.e. XP vs win7) from when it was working properly?

[MarkCG]

Changing the call library node to stdcall (WINAPI) did the trick! No more crash. Thank you very much!

I haven't run LV2011 on windows XP, only on windows 7, so I don't know if that makes a dfference. But  The call type makes no difference when using LV 8.6 on the same machine, however.

Now I've got to make the .DLL run corretly on a compact fieldpoint....  and avoid crashing IT. 

Thank you for the help all!

[rolfk]

---

@MarkCG wrote:

Changing the call library node to stdcall (WINAPI) did the trick! No more crash. Thank you very much!

I haven't run LV2011 on windows XP, only on windows 7, so I don't know if that makes a dfference. But  The call type makes no difference when using LV 8.6 on the same machine, however.

Now I've got to make the .DLL run corretly on a compact fieldpoint....  and avoid crashing IT. 

Thank you for the help all!

---

@well, the DLL did work fine in LabVIEW 8.6 because earlier versions of LabVIEW automatically proceeded to change the calling convention to stdcall, if they noticed a function name decoration of @# (# = number of bytes passed on the stack) appended to the name. This is the default naming decoration for stdcall functions used by VisualC. However this decoration can be overwritten with linker switches, other compilers don't use them always in the same way, and most likely there are in the mean time compilers out there that can produce such decorations also for non stdcall calling convention. So this automagic trickery was removed from newer LabVIEW versions.

I do think it could be considered a bug in the code that upgrades LabVIEW VIs, that it uses the calling convention that is configuerd in the dialog, instead of the calling convention earlier LabVIEW versions used automagically, but it is an esoteric corner case.

What Compact Fieldpoint controller do you have? If it's anything newer than 20xx or 21xx forget it. The 22xx controllers use a PPC CPU and VxWorks operating system and can never get a Windows DLL to operate properly. If it is a 20xx controller it's still highly likely that DLL can not even get loaded into LabVIEW as it likely relies on other runtime libraries and possibly Win32 APIs not present in the Pharlap ETS runtime kernel used on those controllers.

There is a tool to check a DLL for incompatible imports that are not present on specific ETS RT systems. And this list summarizes the RT system used on the various NI controllers.

[MarkCG]

Hi Rolf,

Fortunately, there are plenty of 21XX model Compact FieldPoints here. There was some concern where I work that we couldn't start using LV2011 because of .dll incompatibility problems. I'm sure someone used tried using code that called some of those Windows DLLs on a cFP2200 and declared that it was a LabVIEW 2011 problem, rather than a hardware problem. I did find out about from an NI rep in my area the fact that anything running the VxWorks RTOS would not be able to run Windows DLLs. This clears up a lot of confusion. 

I was wondering what all the various symbols appearing in the function prototype name...  Thank you for that little tidbit. In my very limited C programming experience I hadn't seen those before. 

I know the .dll (let's call it "mystery.dll") in question was made to run on a cFP 21xx before, which was running Phar Lap ETS 13.1 , or LV Real-Time 8.6 that is, according to the link you posted. I had used the DLL checker tool before and saw that it relies on several MORE .dlls itself. So I am assuming as long as I put ALL the various  .dll that "mystery.dll" calls, such as cvi_lvrt.dll,  msvcp71.dll, and msvcr71.dll in the "c:\ni-rt\system" of the cFP, I SHOULD be ok. Hopefully. 

 What I'll probably need to do is take the source that IS out there, and recreate all the "glue" code (which is MIA) that allows it to be called as a .dll, and compile it in such a way that it can be called by both Pharlap and VxWorks. I'll have to do more research to see if that's possible. I see that you can compile for VxWorks withe GNU toolchain,link so that's good....  Or worse comes to worse load two different version of "mystery.dll" depending on what the target is. 

Thank you for help! It's much appreciated. I am starting to um, empathize with those who have to grapple with "legacy" code.

Regards,

Mark G.