Need help with an error report

[MinerHokieRamp]

Attached is an error report from a VI that normally crashes with Error Checking set to Default in the VI's LCFN configuration dialog box. Can't debug it when it crashes; LabWindows CVI comes up for debug but CVI crashes too.

The attached error report was only available after setting Error Checking to 'No Error Checking'.

Any ideas what's going on with this DLL function called by the LCFN?

Platform: Windows 7-32 + LV2013 Pro SP1-32.

Jeff

[ConnorM]

Jeffrey,

By LCFN do you mean the Call Library Function Node? The log you have posted suggests that you are getting an Access Violation error. Often this error happens in this case:

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

If this is not the case, please post more information on what is going on before the crash. 

-Connor

[MinerHokieRamp]

Connor,

Sorry, I meant CLFN.

This isn't an executable.

It's good LV2009 code (ran okay with LV2009)  that I'm trying to execute with LV2013. I ran a mass compile on all the VIs.

I posted this issue a few months ago when using an evaluation copy of LV2013 but have only recently begun looking at it again after I installed our purchased copy of LV2013.

I can prevent LV crashes from this VI by changing its calling convention from "C" to "StdCall." However, the value returned from the DLL function is invalid. While the DLL function returns an invalild value, I added "unbundle by name" VIs to the error stream on the input and the output of the CLFN. Results: the error 'code' at the input and the output of the CLFN = 0.

The supplier of the DLL said the DLL functions are written in either C or C++. I've found notes at ni.com that indicate a "Wrapper DLL" (written in C) might be required to provide a "C to C++" translation  interface between the CLFN and the DLL functions.

Another approach I've found on ni.com appears to be replacing the CLFN with a Code Interface Node (CIN) having C code to interface LV with the C++ code of the DLL function, thus eliminating the CLFN.

There are also some notes on ni.com concerning CLFN settings causing crashes in the LV2009 to LV2010 transition; apparently, other changes between LV2010 and LV2013 are causing my issue.

The supplier of the free DLL now has a LV developers kit  (for purchase) that might solve these issues but we can't go that route.

Thanks,

Jeff

[ConnorM · Accepted solution]

Jeff,

I think these KBs are what you were talking about.

http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672?OpenDocument

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

 The typical fix for this crash it to switch from C to StdCall. How is the value of the function invalid?

Can you post this free dll (or a link to it) so that we can try to replicate the issue?

-Connor

[MinerHokieRamp]

---

@ConnorM wrote:

Jeff,

I think these KBs are what you were talking about.

http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672?OpenDocument

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

 The typical fix for this crash it to switch from C to StdCall. How is the value of the function invalid?

Can you post this free dll (or a link to it) so that we can try to replicate the issue?

-Connor

---

Connor,

I've been working on another project for a few weeks and just now getting back to this.
 
After recently configuring DDC's MIL-STD-1553 card with the card manager utility again, the VI returns valid data.

However, there were a total of 11 VIs that had this issue. Using the card manager to rescan the hardware seems to have cleared up most of the issues. Now, it appears that only one of those VIs returns invalid data.

I appreciate the offer to try and replicate the issues, but you'd need our LV code and the DDC hardware as well.

Can you explain why using the 'stdcall' calling convention works better than the 'C' calling convention when calling C functions (i.e., these aren't .net functions in the DLL)?

-Jeff

[0utlaw]

Hello Jeff,

The calling convention is usually defined by the compiler, for reference:

http://en.wikipedia.org/wiki/X86_calling_conventions

I belive the second KnowledgeBase Connor linked describes how the incorrect declaration would be overridden by the compiler prior to LV 2010.

Best Regards,

[MinerHokieRamp]

Tom,

All the function prototypes in the DLL's header file have _DECL for a prefix. The wikipedia articles said _CDECL would be the prototype prefix for C calling convention.

Still gotta figure out what's going on with that last VI.

Thanks,

Jeff

[MinerHokieRamp]

---

@JeffreyP wrote:

Tom,

All the function prototypes in the DLL's header file have _DECL for a prefix. The wikipedia articles said _CDECL would be the prototype prefix for C calling convention.

Still gotta figure out what's going on with that last VI.

Thanks,

Jeff

---

I found a way to make that last "problem" vi work. The hardware was in the wrong state when the vi was called. The 'ready' state is required.

A VI that transitions the hardware from the 'ready' state to the 'run' state was moved so it excutes after the "problem" VI, not before. After moving that VI, the error code is not returned by the DLL function.

Actual overall success of transition of the code from LV2009 to LV2013 is TBD pending results of tests in the lab next week.

Still don't understand why the code worked with the hardware in the 'run' state when executed by LV2009 and didn't work when executed by LV2013.

Thanks,

[billko]

---

@JeffreyP wrote:

---

@JeffreyP wrote:

Tom,

All the function prototypes in the DLL's header file have _DECL for a prefix. The wikipedia articles said _CDECL would be the prototype prefix for C calling convention.

Still gotta figure out what's going on with that last VI.

Thanks,

Jeff

---

I found a way to make that last "problem" vi work. The hardware was in the wrong state when the vi was called. The 'ready' state is required.

A VI that transitions the hardware from the 'ready' state to the 'run' state was moved so it excutes after the "problem" VI, not before. After moving that VI, the error code is not returned by the DLL function.

Actual overall success of transition of the code from LV2009 to LV2013 is TBD pending results of tests in the lab next week.

Still don't understand why the code worked with the hardware in the 'run' state when executed by LV2009 and didn't work when executed by LV2013.

Thanks,

---

I sense some kind of race condition that only became apparent when LV was ugraded and now the thing that was always winng the race is always losing the race.

[MinerHokieRamp]

Maybe. Time will tell.

I thought the code would be more robust if I could sense the hardware state before execution and then change the state as required. Unfortunately, I couldn't find a function that returns state of the hardware.

Thanks,