LabVIEW Crashes When Calling DLL with Exception 0xc0000005

Issue Details

• LabVIEW is crashing when I call my DLL, and I get an error message with saying a memory access violation has occurred (Exception Code: 0xc0000005).
• I changed my version of LabVIEW from 32-bit to 64-bit and now my application randomly crashes with Exception Code: 0xc0000005

Solution

There are several different reasons LabVIEW might crash while calling a DLL function methods to prevent this type of crash are listed below:

1. Make sure you are using the same calling conventions as the DLL
If the calling convention specifiec in the Call Library Function Node does not match the calling convention of the DLL, it will cause a crash. The calling convention is specified in the lower right portion of the Call Library Function node window, as seen below.
2. Make sure that you wire all inputs and outputs of your Call Library Function Node
If you do not wire the all of the inputs and outputs of a Call Library Function Node, the DLL function will overwrite unallocated memory and cause LabVIEW to crash.

Note: If your second input is a pointer to your first input, then your first input does not require an output.

3. Make sure the DLL function is not overwriting LabVIEW memory
If not enough memory is allocated or the DLL function writes more than has been allocated, the DLL will overwrite reserved LabVIEW memory space and cause LabVIEW to crash. Make sure that memory is allocated properly before passing in and reading out arrays, strings, or waveforms from DLLs.

4. Make sure that LabVIEW is passing parameters to the function in the format that the function is expecting
Calling the DLL function from LabVIEW with incorrect parameter datatypes (by value, reference, handle, etc.) can cause the function to unintentionally point to an incorrect memory location resulting in faulty data, or even a crash of LabVIEW or Windows.

5. The function call itself does something illegal
If a function attempts to perform an illegal operation, it might crash LabVIEW. If you are not the author of the function, contact the writer of the function.

Additional Information

1. When using the C calling convention, the caller is responsible for cleaning up the stack. When using the standard calling convention, the called function is responsible for cleaning up the stack. If the caller (LabVIEW) and the called DLL function do not use the same calling convention, then they will either both take things off the stack or neither of them will. Either situation can cause LabVIEW to crash when the called function returns.
2. If you do not wire the inputs, the DLL function will overwrite unallocated memory. If you do not wire the outputs, LabVIEW assumes the DLL function does not need the allocated memory passed on the input side and will use it for something else.
3. Many DLL functions take allocated memory, passed by pointer or value, write to this memory, and return it. If the memory is not allocated properly, it may cause a crash. For example, consider the following function: 
   
   double *Waveform (double *waveform, uInt32 size); 
   
   The proper way to allocate the memory in this case is to initialize the array with the number of elements specified by the size parameter, not by passing in an empty array. The image below demonstrates the proper method.

If you built the DLL in LabVIEW and you want to show the front panel of the DLL VI, there are two requirements that you must follow.

1. The Call Library Function Node must be set so that the DLL call is allowed to run in any thread. This is set by changing the thread radio button from Run in UI thread to Run in any thread.

2. The calling VI must not be running in the User Interface thread. This can be checked by selecting File»VI Properties from the pulldown menu, selecting Execution from the Category list and making sure that the Preferred Execution System is standard, instrument I/O, data acquisition, other 1, or other 2. The same as caller option should not be chosen because the parent VI could be running in the user interface thread.

For complete documentation on how to use LabVIEW code with other programming languages in LabVIEW 7.1 or earlier, refer to the Using External Code in LabVIEW manual. In LabVIEW 8.0 or later, refer to the Fundamentals>> section in the LabVIEW Help table of contents for more information.

Note: Your VI might still run in Development mode without following these steps. However, when making an application, be sure to set the the calling VI to Run in any thread as stated above.

If LabVIEW does not crash until it is closed
The most likely problem is that the DLL function being called has corrupted the memory. If you pass arrays or strings to the DLL, the DLL function cannot dynamically resize the array. Writing beyond the last element of the array or string could corrupt the memory and this may not be obvious until LabVIEW is closed.

Error Checking—Use the Error Checking tab to specify the error checking level for the Call Library Function Node.

This tab includes the following components:

• Error Checking Level-Contains the following options:
  •  Maximum-Enables the maximum level of error checking for the Call Library Function Node. If you enable the maximum level of error checking, the Call Library Function Node returns an error if the Calling convention you select on the Function tab does not match the calling convention of the function you are calling in the shared library or DLL. The maximum level of error checking also returns a warning if the function being called in the shared library or DLL writes beyond the space allocated for the specified string or array parameter. The maximum level of error checking allows LabVIEW to recover from unhandled exceptions that occur during execution of the called shared library or DLL.

• Default-Enables the default level of error checking for the Call Library Function Node. The default level of error checking allows LabVIEW to recover from unhandled exceptions that occur during execution of the called shared library or DLL.
• Disabled-Disables error checking for the Call Library Function Node. Disabling error checking for the Call Library Function Node improves the execution speed of the Call Library Function Node. However, certain errors can cause an irregular shutdown of LabVIEW. Before disabling error checking, be sure that the function the Call Library Function Node references does not raise any unhandled exceptions.