Crash "DAbort 0x37C03D in MemoryManager.cpp" when calling DLL with "Call Library Function Node"

Hi all,
I would like to work with a LabVIEW program that I did not programm by myself.
In this programm an external DLL needs to be called. in the Momente this dll ist called with the "Call Library Dunction Node" LabVIEW crashes with this Error Message:
DAbort 0x37C03D in MemoryManager.cpp
Attached is the entire Log.
The programm runs on the computer of the original programer.
I have never handeled with DLLs or something like that before, so I have absolutely no idea how to rsolve this problem.
Thanks for your help!
Attachments:
lvlog.txt ‏2 KB

A DLL can be compiled by different compilers. By "generic" C DLL, i refer to ANSI C (so no C++, no Borland C or something else).
My question is raised as parameters, esp. arrays and strings, can lead to this behavior when used in the wrong way (including "Calling Convention").
Also, interfacing with the LV memory manager can lead to crashes like this, but this wouldn't be a "generic" DLL as it binds to LV (due to LV API calls).
Without a better knowledge on the DLL and its functions, there is not much we can help you with.
Where does the DLL come from?
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Similar Messages

LabVIEW PDA reports COREDLL.DLL error when using Call Library Function Node

I'm trying to build a LV PDA app that calls an external DLL file built using embedded visual C. When configuring the Call Library Function node I select the stub DLL, configure the I/O parameters and select OK. When the configuration dialog closes I get the following error:
LabVIEW: LabVIEW.exe - Unable to Locate Component
This application has failed to start because COREDLL.DLL was not found. Re-installing the application may fix this problem.
I do not get this error when using the configuration dialog in the example VIs.
Any suggestions as to the cause and/or the solution?
Thanks,
Ryan

Hello -
When you create a PDA VI that calls a DLL, you must include the .c or .lib file that corresponds to the DLL. Take a look at these documents:
LabVIEW PDA Module Build Errors with VIs that Call DLLs
Why Do I Receive Errors When Calling a C++ DLL from a Call Library Node Using the LabVIEW PDA Module...
How To Call External Code in LabVIEW PDA for Palm OS
H
ow To Call External Code in LabVIEW PDA for Pocket PC
Hope this helps!
S Vences
Applications Engineer
National Instruments

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time it is called?

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK? Could any senior developer assure me?
Thank you in advance.
Solved!
Go to Solution.

qing_shan61 wrote:
When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
Once
qing_shan61 wrote:
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK?
OK
Be sure that all DLL calls are thread safe (do not perform calls in UI thread).
Also for real-time application you need real-time OS.
Andrey.

Failed to run parallel path when using call library function node in LV2009

I have a problem with two parallel paths not being run in parallel on LabView 2009.
See the image below.
This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
Is there some limit on parallel threads that is different in 2009 than in other versions ?
Or is there some other problem in 2009 that might cause this problem ?
My labview version is 9.0f3 (32-bit).
Regards,
Rob

I've just installed the DETT tool and checked what the different versions of LabView do.
In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
To answer Ben's question: "What thread does a modal VI run in?":
In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
Thanks,
Rob

Executable created in LabVIEW 7.1 containing Call Library Function Node runs but creates error when Call Library Function Node is executed

I have created a simplee application that controls a piece of equipment with all control via a supplied dll. Hence, there are a number of Call Library Function Nodes within the code and a modicum of other LabVIEW code. Everything works fine as a LabVIEW application, but when converted to an executable, although the application runs and functions, as soon as any Call Library Function Node is executed, calling from the dll, I get the C++ debug error in the attachment.
Is this something that I can solve from within LabVIEW, or is the problem likely buried in the dll?
Damian
Attachments:
CLFN error.JPG ‏22 KB

Hi Wise,
Try building an executable from a very simple VI that makes one call to the dll. Have you also try using the Call Library Function node on other simple dlls that you know will work?
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

Fatal internal error: memorymanager.cpp, line 566

Hello all
I have been seeing this error sicne recently, when I run a test sequence in TestStand 2010 SP1, f1. I call dll made in NI LabVIEW 2010 SP1, f4.
I had been using this test sequence and dll functions since almost two months. but its just since last couple of days that I receive this error.
I also get a TestStand execption and then the TestStand would crash. the reason why I am posting it here is because, when I do not run the step which has this dll call, I do not get the error. My entire tests runs over days. As soon as I include this dll call in the test, I keep getting this error.
Along with this MemoryManager error, I also see "TestStand Exception" and "TestStand has to close due to an error".
The dll function has been developed using LV 2010 SP1. That is a monitor VI whose front panel will be opened using dll call. I pass a test file name using the dll calls and then the VI will open the TDMS file and display the data till I click Stop.
this TDMS file is being written into, inside a datalogging dll which is also launched from TestStand. This dll is also developed in LabVIEW by us.
I have been using this setup since weeks and now I get this error. Also, I get this after I had upgraded both TS and LV to the latest fixes (f1 and f4).
But the help for this error on NI website actually says we should upgrade to the latest fix inorder to avoid this error!!
I will post this also on the TS board.

Same error. TestStand 4.2.1 calling LabVIEW 10.0.1 (2010 SP1).
Joe Gerhardstein
Averna Test Systems
Certified LabVIEW Architect
http://www.averna.com
Attachments:
error.JPG ‏18 KB

How to show the front panel when launching VI with Call by reference node??

Hello!
I just wonder how I make the front panel visible during execution when I launch the VI with CALL BY REFERENCE NODE.
Se example.
Could u also show me how to change different properties (window size ..) of the front panel??? (launched with CALL BY REFERENCE NODE)
Thank you!
Attachments:
test.vi ‏18 KB

In VI Properties>>Window Apperance>>Customize you can check "Show front panel when called". This will open the front panel on each call. It doesn't matter how the call was initiated.
You can set a lot of Front panel properties during runtime. Place a Property Node in the block diagram. Change the class from App to VI. Under properties select Front Panel window>>Panel bounds to set the position and size of the front panel.
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Error when building DLL using Keithley library

I'm trying to build a Labview Shared DLL of my VI's, however I'm using Keithley's KPCI-PIO24 Labview driver. When I include any of their library calls into my DLL, I will get a "LABVIEW.LIB was not called from a Labview process". I have mass compiled all the Keithley libs but this hasn't helped. Any ideas??
Bob Wirth

I am not 100% sure but I beleive that the KPCI line of drivers are DOS based. I know that Keithley's GPIB driver is DOS based. I am not sure about the labview drivers. This may have some effect on building a DLL. You may have to settle for building a llb instead of a DLL.
- tbob
Inventor of the WORM Global

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

PDA: Calling library functions - seems to link the stubbed .cpp file instead of the DLL

I'm having trouble developing a Lab View PDA module that calls a DLL built using Visual C++. The DLL functions correctly when called in a non-PDA VI. My issues seem to be with porting to the PDA.
My configuration:
- Lab View 8.5 with the PDA 8.5 module
- Visual Studio 8.0 with the Windows Mobile 6.0 SDK
- ASUS 626 PDA with an Intel PXA70 procesor running Windows Mobile 6 Classic
Following the PPCBatt example code provided with the PDA module, I have:
- used extern "C" to prevent name mangling
- placed the DLL built with the Windows Mobile SDK in the \Windows directory on the PDA
- created a stub Win32 DLL and lib
- created a stubbed cpp file whose functions only return zero
- included the stubbed cpp and lib files in the build spec / source files / additional files
- placed Call Library Function nodes on my PDA VI, selected the function names, set the parameter types
- built and deployed the executable, both with and without debug
When I set the library path property of the Call Library Node, the functions appeared in the function name pulldown, but the parameters did not populate. I had to manually add them and set their types. The help page says they would autopopulate when the function was selected.
I've debugged the VI, and the Library Function Call nodes are being called. It seems the build is linking the code from the stub C file provided in the additional files portion of the source files property page, instead of adding hooks to call the DLL on the PDA. As a test, I changed an output parameter in one of the functions in the stubbed cpp file - the changed value showed in the front panel indicator.
What am I doing wrong?
Dan

Hi Dan,
I'm not sure if I understood you problem fully. When calling external code with LabVIEW PDA, the DLL acts as a stub DLL with the correct function prototypes for the C code that you want to call. Here's a Knowledge Base article that might help explain about calling External Code in LabVIEW PDA.
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

Can I make dll with cpp files?

Can anyone tell me whether I can make dll from a *.cpp file and call it
from the call library function node in LV? I am getting this doubt bcoz
when I right the Call Librarry function node, the calling convention is
C and not C++.
Thanx & Regards,
Srini.

Check out this previous post and be sure to read the External Code Reference Manual.
Jason

I have a Ipod touch and recently added new music to my itunes library on my laptop. When I sync with my ipod, the new music does not show up on my ipod even though the sync process seems to be working.

I have an Ipod touch and recently added new music to my Itunes library. When I sync with the library, the new music does not show up on my ipod. The sync process seems to be working and there is still plenty of space on the Ipod for new music so I'm not sure what the problem is!

What happens when you try to sync?
Was the iPod previous synced to another iTunes library/computer?
Have you successfully synced from this iTunes library/computer before?
Do the songs play in iTunes?
Do you have the right boxes checked to sync?
iTunes: Syncing media content to iOS devices and iPod
Do you have any Restrictions (Settings>General>Restrictions) set that would prevent syncing those songs?

Creating dll and calling it in labview crashing the program

Hi All,
I am using labview from quite a long time.But this time i am stuck with dll.Not able to solve this issue.
I have to communicate with FTDI chip.
I have a VC++ Project to communicate with SPI of FTDI.That Code is working perfectly fine.
Now I Have to automate that through LabVIEW. VISA Drivers i cant use in this. So Last option left is either to create dll or to make EXE out of it.
I have tried by creating DLL and then calling it in LabVIEW by using Call Library Function Node.But its not helping me out every time LabVIEW is getting Crashed.
Is there error in creation of dll or something i am not doing properly while calling?
Thanks In Advance
Shweta
Attachments:
old_dolphin_sub_spi_func_ftdi.c ‏21 KB
ftdi_write_read.vi ‏15 KB

Which function call crashes LabVIEW?
Have you tried switching the calling convention from stdcall to C for all of the DLL calls?
Why are you converting a string to a number, instead of using a numeric constant directly? If you want a number in hex, you can right-click a numeric constant, make the radix visible, and switch it to hex display.

Labview hangs when accessing dll

Im accessing an active x dll using labview 8.21. When we query the dll all parallel loops in labview hang until the dll returns. Is there a way to get around this behaivour?

HI,
I do not know if this will help, but there is an issue with the Call Function Library node in LabVIEW 8.2.1 and is posted in the LabVIEW 8.2.1 Readme help here:
If you configure a Call Library Function Node to call a LabVIEW DLL, place a checkmark in the Specify path on diagram checkbox on the Function page of the Call Library Function dialog box, and select Run in UI thread in the Thread control, LabVIEW hangs when executing the Call Library Function Node. To correct this problem, select Reentrant instead of Run in UI thread in the Thread
control. If you configure the Call Library Function Node to call a DLL
written in C with these same settings, LabVIEW works correctly.
I hope this helps,
Regards,
Nadim
Applications Engineering
National Instruments

Error 1097 when calling dll

I'm using more than 20 functions from a .dll code to Labview and have in some of then the 1097 error.
Error 1097 occurred at Call Library Function Node
Possible reason(s):
LabVIEW: An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.
I have read a lot about this error and I still didn't find a solution.
Thinking that could be a problem on the configuration of the VI, I imported it again and this solved the problem in the first VI. I did the same with the second one with an error but this time didn't solve.
The weird is that this VI with the error (intRun):
_API void intRun_ ( int* run_ , int* devList_ ,int* numDev_, char* retval )
it is exactly the same as another (anaRun) and this I don't have the error:
_API void anaRun_ ( int* run_ , int* devList_ ,int* numDev_, char* retval )
Inside the C code they look like the same (but each function will run a different device) and the configuration in Labview is also the same.
Is that possible that I have any problem with my device? Or could be really a problem with the .dll or with the VI?
I read something about wrappers but really I don't understand why I have the error with one VI and don't have with the other (running together) and how (or if) the wrapper could solve my problem.
Please give me any idea what I could try.
For example, I tried to disconect the input numDev (that is a constant, always 1) and then I don't have the error. Why?
Best Regards,
Thais

Thank you for reply.
I'm using LV09.
Actually I figured out that before this VI that I have the error the device is not working as should be .
When running the program step by step I realized that what I was expecting to happen (locking ports before initialization) didn't happen.
So it is probably a bad configuration of the other VIs that I have (there is no Error but returns me an Bad Argument in the return_output);
I will try to solve it and then I tell here if it was really that.
Thak you all.
Thais

Crash "DAbort 0x37C03D in MemoryMana​ger.cpp" when calling DLL with "Call Library Function Node"

Similar Messages

Maybe you are looking for

Crash "DAbort 0x37C03D in MemoryManager.cpp" when calling DLL with "Call Library Function Node"