LabVIEW crashes when calling a dll

I am trying to call a dll through my LabVIEW program. The dll implements a routine to access an ftp server. When the server is found, everything works as expected. However, if there is a delay in finding the server, LabVIEW throws an error � �An exception occured within the external code called by the Call Library Node�. The detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found (it returns a signed integer). This error message pops up after roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.
Attachments:
LabVIEW_error.jpg ‏14 KB

Hi,
If you call a dll, everything should be just right, or it will crash (if you
use LV7, you're lucky, most of the times LV stays alive, and only gives a
message).
The first thing that should be checked is the calling convention. This
should probably be "stdcall (API)". This changes the way the parameters and
return address are pushed to the stack.
The second point are the parameters. Pointers should be set to pointers,
LONG to i32 etc. The return parameter can always be set to i32, or to
nothing.
My best guess is (since the dll crashes after a while), there should be a
pointer to a buffer (most likely a cluster, but could be a reference). The
connection succeeds, and the dll copies the information to the pointer. If
the pointer is not valid (the memory does
not belong to LabVIEW), an
exception is raised.
Perhaps you can give a function prototype? The prototype is the way to
start.
Regards,
Wiebe.
"gopinath" wrote in message
news:[email protected]..
I am trying to call a dll through my LabVIEW program. The dll
implements a routine to access an ftp server. When the server is
found, everything works as expected. However, if there is a delay in
finding the server, LabVIEW throws an error - "An exception occured
within the external code called by the Call Library Node". The
detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found
(it returns a signed integer). This error message pops up after
roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.

Similar Messages

Why does LabView crash when unloading my DLL (reentrant calls)?

I have written a DLL in Borland Delphi using multiple threads that exports several functions (stdcall). I am using LabVIEW 6i on a WinXP machine. All functions in the DLL work as expected and return correct values. Everything works fine if I set all Call Library Function Nodes to 'UI-Thread', but as soon as I set one Function Node to 'Reentrant', LabView crashes when I close the VI after it has been executed. I assume the error is caused by the DLL unloading mechanism of LabView. Other C++/Delphi programs using the DLL reentrantly work fine, this only occurs in LabView. In which thread does LabView call FreeLibrary/DLL_PROCESS_DETACH? Has anyone experienced similar problems?

I have never run into this situation myself, but I do know that calling a multi-threaded DLL or CIN from LabVIEW does depend upon the following criteria:
If your CIN/DLL doesn't have any global data storage (global variables, files on disk, etc.), AND it doesn't access any hardware (register-level programming) AND it doesn't call any functions/DLLs/Drivers that are thread-unsafe.
OR
Your CIN/DLL protects (with semaphores or mutex's) access to those global resources.
OR
Your DLL is only called from one, non-reentrant VI
OR
Your CIN is only called from one, non-reentrant VI AND you don't access any global resources from CINInit, CINAbort, CINDispose, etc. procedures.
Hopefully this information can help you out in some way.
J.R. Allen

LabVIEW 2010 crash when calling user32.dll

Interesting LabVIEW 2010 "feature" I discovered this morning.
Attached are two identical VIs, one saved in 2010 and one saved in 2009. These VIs were specifically written to demonstrate the bug I stumbled upon this afternoon. Each VI when run should allow you to find a specific program (window) open in Microsoft Windows and bring it to the foreground. It relies on "user32.dll" to perform this operation. It also allows you to specify the calling convention for the function call.
In LV 2009, either calling convention works, without error. However, in LV 2010 the calling convention for the function must be "stdcall (WINAPI)" and not the default "C". If the calling convention is "C" then LabVIEW crashes and closes without warning.
If you happen to have both LV 2009 and LV 2010 on your computer, I would love to hear if this phenomenon is duplicated so that I can pinpoint whether the bug is LV 2010 related or is more specific to my personal setup.
Thanks,
~David
Solved!
Go to Solution.
Attachments:
LV2010 test.vi ‏13 KB
LV2009 test.vi ‏14 KB

221113
Return
CLFN with the wrong calling convention may siliently crash LabVIEW.
LabVIEW 8.5 through 2009 could adjust the calling convention at run time if the user selected the wrong option. In 2010 this no longer happens. More information is found in KnowledgeBase 59KB14WI
Workaround: Use the correct calling convention
Reported Version: 2010 32-bit
Resolved Version: N/A
Added: 07/23/2010
From 2010 release notes.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

VB6 applications crashes when calling C# dll's in production environment

Hi All,
I'm basically .NET developer, not much aware of VB language or VB visual Basic 6.0.
We are trying to work out with VB application running/ using C# dll's. The scenario is like VB exe applications using C# dll's and C# dll's are referenced to VB application using .tlb file.
In development environment(debug mode) the application looks fine and working as expected. But when the same code is put into production environment VB applications are crashing when pointing to C# method calls. We trying to know the reason but application
is getting killed. The issue seems to be sporadic and not able to catch in MsgView(debug tool).
In one more scenario, the VB application is loading C# form and getting data back to VB but when we repeat the same workflow again application is crashing either in 2nd attempt or 3rd attempt.
Has anybody seen such issue? Any input is welcomed.
Thanks,
Shesh

Hi Shesh.ugare
Welcome to MSDN.
I am afraid that these forums donot support VB6, you could refer to this thread:
Where to post your VB 6 questions
If this issue regarding VB6 then you could consider posting this issue in these forums below:
These forums do not support Visual Basic 6, however there are many third-party support sites that do. If you have a VB6-related question please visit these popular forums:
VB Forums
VB City
If not, then you could share more detailed code with us.
Thanks for your understanding.
Regards.
Youjun Tang
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Array limitation when calling VB Dll?

Today I encountered a problem when calling a Visual Basic DLL in Labview 8.2.1
I had to pass a 3D Array, with one dimension exceeding 30 000. around that array size I ended up with error -2146828282 when calling the Dll.
The dll was working fine for weeks. So, is there any limition to the array size, which could cause the error?

Hi sthu,
Having 30,000 elements in one dimension of an array should not cause any problems by itself. The maximum number of elements per dimension in an array is (2^31) – 1 as described in the LabVIEW Help for Grouping Data with Arrays and Clusters. However, this is also dependent upon the memory available in your computer. If there is not enough memory available in RAM, you might receive an error when passing the array to the DLL.
I have included a couple links to pages that discuss LabVIEW memory usage and managing large data sets in LabVIEW. These might help get your application up and running with the larger array sizes.
VI Memory Usage
Managing Large Data Sets in LabVIEW
Donovan

Labview crashes when creating large image files

I have a problem with Labview 6.0.2( I've tested evaluation version 7.0 too).
I'm constructing a very large image, for example: 4500x4500 pixels. Labview crashes when converting the pixture to a pixmap. The image is fully constructed on my screen (in a picture control), but when converting it to a pixmap (for saving the image in a known format (bmp, jpg, tiff)), Labview crashes.
I did some testing and when the number of pixels exceeded the limit of 2^24(16777216), the file 'image.cpp' crashes on line 1570. The vi to convert it to a pixmap is: P'icture to pixmap.vi'
Does someone know a workaround for this problem? Or is there a fix for it?
Thank you!

I've tested the 6i version of my VI in Labview 7.0 evalutation version. It raised an error but not the same error:
d:\lvworm\src\lvsource\compatexport.cpp(37) : DAbort: Called a routine not in the compatibility LVRT table
$Id: //labview/branches/Wormhole/dev/lvsource/compatexport.cpp#11 $
0x004BD4CB - LabVIEW_Eval + 0
0x0EB710D9 - lvs248 + 0
0x094C87A0 - + 0
So i replaced the picture VI's with the 7.0 evalutation version VI's, and it worked. It is now possible for me to construct very large image files!
I see no attached VI to test. But i guess it is also solved in Labview 7.0
I used this file to convert the picture to image data:
C:\Program Files\National Instruments\LabVIEW 7.0 Evaluation\vi.lib
\picture\pictutil.llb\Picture to Pixmap.vi
And this file to convert image data to bmp:
C:\Program Files\National Instruments\LabVIEW 7.0 Evaluation\vi.lib\picture\bmp.llb\Write BMP File.vi
I guess i have to write a workaround for this problem:
divide the picture in blocks of 4096 x 4096 and then merge the image data arrays of the bloks together.

LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.

Hello, LV 8.2.1 notes indicates the following bug fix:
43SAIR2A Fixed an issue where LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.
I am running this version, and still have this behavior. Is there anything I may be missing, and/or certain circumstances that may still be causing this?
thanks in advance,
Darren

Darren:
I looked at the CAR ID that you mentioned and the issue has been resolved in LabVIEW 8.2.1. To verify something similar, I ran the attached VI and things worked just fine. Please feel free to send me the steps to follow to reproduce the issue you are running into in 8.2.1.
Regards,
Rudi N.
Attachments:
MixedGraphs.vi ‏15 KB

LabView crash when intensity graph is in P6 of tab control

Any available fixes for LabView crash when intensity graph is put on page 6 of tab control and right-clicked??

Michael,
This has been fixed in LabVIEW 6.1.
Regards,
Cyril Bouton
Applications Engineer
National Instruments
Cyril Bouton
Active LabVIEW Developper

LabVIEW Crashes when Opening Project

Hey Guys,
I'm running into an interesting issue where LabVIEW crashes when opening a project. This is the second time I've run into this issue, on the same project. To get around it the first time I simply deleted and re-made my project, but since it's happened again, I need to figure out how to debug it. The symptom is that LabVIEW will crash when opening the project (sometimes I can see the "vi loading" screen) without any indication that crash has occured. It doesn't even launch the error reporter, the process just dies. Anyone know how I can go about debugging this?
Solved!
Go to Solution.

xkenneth86,
What version of LabVIEW? Have you ever had previous versions of LabVIEW on your computer? Can you attach a screenshot of the crash?
David H.
National Instruments

LabVIEW crashes when I save changes to a particular VI.

LabVIEW crashes when it tries to compile a particular VI. I have managed to get it to work a couple of times by changing a few things and making some subVIs, but the problem keeps returning.
Is there some way to fix this or clean the VI of whatever corruption keeps occurring?
Thank you,
David R. Asher

I can think of address/hardware conflicts or something that LabVIEW cannot provide an error message. I would go with hardware/address conflicts.
Try renaming the file and executing it stand-alone. also try making it as a subvi and run the toplevel code.
Kudos always welcome for helpful posts

Application crashes when calling DLL built with LabVIEW 2011

Hello everybody,
Our application calls DLLs built with LabVIEW 2010 SP1. We installed LabVIEW 2011 and built some DLLs. So far so good. If we start our application and run 2010 DLLs it still works fine. If we run a 2011 DLL just once no error happens, but if we try to run the same 2011 DLL our application crashes reporting the error below. I saved the code for 2010 version and built a DLL and it works fine. Does anyone know why?
Thank you in advance.
#Date: Fr, 16. Sep 2011 16:25:25
#OSName: Microsoft Windows XP Service Pack 3
#OSVers: 5.1
#OSBuild: 2600
#AppName: PasTA
#Version: 11.0f2 32-bit
#AppKind: AppLib
#LabVIEW Base Address: 0x30000000
16.09.2011 16:25:26.181
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: 8a779b3f-51d7-4864-8e4d-6ab0195cd158
ExceptionCode: 0xC0000005
N
0x3072C804 - lvrt <unknown> + 0
0x3072CBB8 - lvrt <unknown> + 0
0x7C864191 - KERNEL32 <unknown> + 0
0x7C83AB50 - KERNEL32 <unknown> + 0
0x00000000 - PasTA <unknown> + 0
Attachments:
error.PNG ‏11 KB

On that note, you should be able to create DLLs in 2010 and run them with 2011, correct?? In my case, I have a 2010 built DLL (talking to sbRIO), most of the functions work when run in 2011, but a couple of them lock up LabVIEW on the desktop (but not the sbRIO), no lock ups happen with 2010 on the desktop.

Stack overflow when calling a DLL

I have developped a DLL in Ada.
I tried to call a function of this DLL from a C++ executable.
My program crashed because of a stack overflow.
Then, I increased the stack size of my program (linker option), and now it
works.
Calling this DLL through the call library function from a 6.0 Labview
program causes the same stack overflow.
How could I increase the stack size of my Labview program ?
Thanks.

Hi,
I have never come across this issue but here are a few things you can try:
1) Change the Calling Convention between C and StdCall(WINAPI). The main difference between the two calling conventions has to do with when the stack is cleaned up. In one method, the stack is cleaned earlier than in the other method.
2) Call your dll with LabVIEW 7.0. You can find the evaluation version of the latest version at http://www.ni.com/labview
Good luck
Feroz

Crash when calling dlll built by LV using timed loop.

I have built a dll with Labview 7.1. Then I use VC++ 6.0 to call this dll. Everything is fine except that it will crash after the whole program finishes. Without timed loop the program can exit normally. When built to exe file, it can also run normally. This happens in both Windows2000 and Windows XP.
Anyone knows the reason for this?
Thanks!

Now the timed loop stops correctly everytime both in Labview environment and standalone exe. But when I call the dll version from C. The c program has no response after the program finishes.
I built another small vi without timed loop to dll and called it. The c program exit normally. What is the problem?
The period of timed loop is 50ms. Is it too short? I found from other post that maybe I should use while loop instead of timed loop. But i need very accurate controling of time.
Any suggestions?
Thanks!

LabVIEW crashes in calling dynamically linked libraries

I am using LabVIEW 7.1 for Linux.
I am interested in writing wrappers around Intel's OpenCV library. The Intel's OpenCV library contains image processing functions. I want to use LabVIEW in order to provide a "glue" for the OpenCV functions.
Using C, I wrote up edge.c which will display a OpenCV HighGUI (basically a GUI window) and wait for an event from the keyboard before closing. It is a very simple program. It compiles and executes correctly.
Using a Makefile, I created the Linux shared library .so file around it. A Linux .so shared library is the Linux's equivalent to the Window's DLL. I named the file edge.so .
When I use LabVIEW's Call Library Function Node, LabVIEW crashed. It just shut LabVIEW down automatically. It did not even display an error message which surprised me.
From the results of this forum message, I decided to write up a C wrapper around the .so file.
I wrote up the following code:
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main()
   void *libhandle;
   int (*edge_func)();
   libhandle = dlopen("/home/elliot/opencv_code/edge_code/edge.so", RTLD_LAZY);
   edge_func = dlsym(libhandle, "main");
   (*edge_func)();
   dlclose(libhandle);
   return 0;
When I compiled and executed the code, it worked fine.
Since I want it to run in LabVIEW, I used LabVIEW's Code Interface Node.
I created a CIN and I have it auto create a C file.
I wrote the following code using the CIN:
#include "extcode.h"
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
MgErr CINRun(float64 *Numeric);
MgErr CINRun(float64 *Numeric)
   /* Insert code here */
   void *libhandle;
   int (*edge_func)();
   libhandle = dlopen("/home/elliot/opencv_code/edge_code/edge.so", RTLD_LAZY);
   edge_func = dlsym(libhandle, "main");
   (*edge_func)();
   dlclose(libhandle);
   return noErr;
When I ran lvmkmf which is the LabVIEW function to create the necessary files, it created the necessary files and the makefile. I ran the makefile and it created the lsb file that is needed.
I used the CIN to call the lsb file. I ran the vi and again, LabVIEW crashed by closing the LabVIEW window without displaying any messages.
If anyone can help me, that will be great! I have no idea how LabVIEW is crashing without displaying any messages. I would assume when I used lvmkmf and the makefile to create the necessary files that it would catch any errors that it did not like. Did LabVIEW crashed because it did not like the call to display a GUI window?

From doing ldd edge.so, the dependencies (at least on the Linux box at work) are:
        libcxcore.so.0 => /usr/local/lib/libcxcore.so.0 (0x40020000)
        libcv.so.0 => /usr/local/lib/libcv.so.0 (0x40117000)
        libhighgui.so.0 => /usr/local/lib/libhighgui.so.0 (0x401ce000)
        libcvaux.so.0 => /usr/local/lib/libcvaux.so.0 (0x401eb000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40250000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40304000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40326000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libdl.so.2 => /lib/libdl.so.2 (0x4032e000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40331000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4033e000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40593000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40601000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4061a000)
        libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4063b000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40648000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4067b000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x4068f000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x406c4000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x406c8000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40732000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40755000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40773000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40782000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407c3000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x407c7000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x407cf000)
        libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x407dd000)
        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x407f0000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x407f8000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4081d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x408fc000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4094d000)

Error when calling a DLL function

Hi,
I am using external C++ code with labView. One of the DLL functions I use serves to call files. The directory and the name of the file is is passed as a parameter for this function. When the VI is running and arrives at this function (I use the Calling Library Function Node tool), the following message is displayed:
ERREUR de type class boost::filesystem::filesystem_error.
boost::filesystem:ath: invalid name "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2" in path: "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2"
I do not know why this message is sent to me.
Thanks for your answer
JF

Hello,
How are you passing the file path to the DLL -- are you passing it as a
string? If you are passing at as a string, I would do some basic
console output to make sure that your DLL is receiving the file path
corectly as a string and perform your appropriate C++ function in your
DLL. If the error is occuring with passing the file path you
might want to check out the links below for a little more information
on this.
http://zone.ni.com/devzone/conceptd.nsf/webmain/7d6a20fe02edbf318625690700704cf3#4
http://digital.ni.com/public.nsf/websearch/4E9234BA4C7C4ABE86256E3C0074760F?OpenDocument
http://digital.ni.com/public.nsf/websearch/3B994675B17C654A86256FDD00754DD2?OpenDocument
Hope this helps,
Travis M
NI
Travis M
LabVIEW R&D
National Instruments

LabVIEW crashes when calling a dll

Similar Messages

Maybe you are looking for