You are here: NI Home > Support > Product Reference > Manuals > LabVIEW 8.5 Help

When you debug your LabVIEW calls to DLLs, you must be prepared to trace problems in the DLL you are calling and in your implementation of the Call Library Function Node in LabVIEW.

Troubleshooting the Call Library Function Node

When your LabVIEW calls to DLLs generate errors, check for the following problems in your use of the Call Library Function Node:

• Make sure the path to the DLL file is correct.
• Make sure the version of your DLL matches the version of LabVIEW, for example, a 16-bit DLL instead of a 32-bit LabVIEW DLL.
• If LabVIEW gives you the error message, double-check your spelling of the name of the function you want to call. Remember that function names are case sensitive. Also, be sure that your compiler has not decorated the function.
• If you receive an error message that a secondary DLL cannot be found, yet you properly specified the path to the primary DLL in the Call Library Function Node, the primary DLL needs additional functions from one or more other DLLs. You need to find the other DLLs and place them in the same directory as the DLL that needs them or in a directory that is in the search path. Refer to the KnowledgeBase at ni.com for more information.
• If your VI crashes, make sure that you are passing exactly the parameters that the function in the DLL expects. For example, make sure that you are passing an int16 and not an int32 when the function expects int16. Check for errors in the code of the DLL, such as dereferencing a null pointer. Also, confirm that you are using the correct calling convention, __stdcall or C.
• Make sure all the parameters are defined to be passed by the correct method, such as value or pointer.
• If you receive a message, the cause is almost always an error in the code of the DLL, such as writing past the end of the memory allocated for an array. Notice that these kinds of crashes might or might not occur at the time the DLL call actually executes on the block diagram.
• If you want to call a shared library that contains ActiveX objects, use the Automation Open VI with the Property Node and the Invoke Node instead of the Call Library Function Node.

Troubleshooting Your DLL

Check for the following problems in your DLL when LabVIEW calls to DLLs generate errors:

• Remember that you need to declare the function with the _declspec (dllexport) keyword in the header file and the source code, or define it in the EXPORTS section of the module definition file.
• When you use the _declspec (dllexport) keyword and you are also using the __stdcall calling convention, you must declare the DLL function name in the EXPORTS section of the module definition (.def) file. In the absence of a .def file, __stdcall might truncate function names in an unpredictable pattern, so the actual function name is unavailable to applications that call the DLL.
• When a function has not been properly exported, you must recompile the DLL. Before recompiling, you must close all applications and VIs that might make use of the DLL. Otherwise, the recompile will fail because the DLL is still in memory. Most compilers warn you when the DLL is in use by an application.
• After you confirm the name of the function, and after you confirm proper export of the function, find out whether you have used the C or C++ compiler on the code. If you have used the C++ compiler, the names of the functions in the DLL are altered by a process called name mangling. The easiest way to correct name mangling is to enclose the declarations of the functions you want to export in your header file with the extern"C" statement, as shown in the following example code:

  extern "C" {

  /* your function prototypes here */

  }

• Try to debug your DLL by using the source level debugger provided with your compiler. Using the debugger of your compiler, you can set breakpoints, step through your code, watch the values of the variables, and so on. Debugging using conventional tools can be extremely beneficial. Refer to the appropriate manual for your compiler for more information about debugging.
• Calling the DLL from another C program is also another way to debug your DLL. By calling the DLL from another C program, you have a means of testing your DLL independent of LabVIEW, thus helping you to identify any problems, sooner.
• When calling a LabVIEW DLL that passes a 2D array, you must first declare the handler variable and initialize the variable to NULL, as shown in the following C code:

  main ( )

  {

         /*LabVIEW data handler variable for the array */

         TD1Hd1myArray = NULL;

         ...

         /* Call to the LabVIEW DLL function */

         DLLFunctionalCall(&myArray);

         ...

  }

  If you do not initialize the handler variable to NULL, the code produces a General Protection Fault when you call the DLL.

• To allow LabVIEW DLL functions to execute without interruption, LabVIEW delays the processing of operating system messages until the end of any calls to DLL functions or until you load a modal window from the DLL. When LabVIEW delays the processing of operating system messages, all function calls to the same LabVIEW DLL are put into a queue. That queue will be executed after the original DLL function call completes. A modal window is a type of window that remains active or remains on top of all other LabVIEW windows until you close the window or open another modal window. You cannot interact with other windows while a modal window is open. Most dialog boxes in LabVIEW are modal windows. You cannot open a non-modal window from a LabVIEW callback VI nor a DLL while any other process is running. If you want your callback VI or DLL to call a non-modal window, you must do so programmatically by completing the steps outlined in the Callback VIs topic.
• You can choose whether to delay operating system messages in DLLs that you build. Before building the DLL, navigate to the Advanced page of the Shared Library Properties dialog box and remove the checkmark from the Delay operating system messages in shared library checkbox to process operating system messages while DLL functions run.