LabVIEW
C program crashes at the end with First-chance exception in InterfaceTest.exe: 0xC0000005: Access Violation reading from position 0x03696000
StefanE wrote:First my configuration:
Labview 8.5.1 / 8.2.1
Visual Studio 2005 standard edition with SP1
now the problem:
I have a huge Labview program compiled as dll. Now I'm calling functions of this dll from my C code. This works fine, but at the end when my c program ends with the return from the main function I get sometimes this message:
First-chance exception in InterfaceTest.exe: 0xC0000005: Access Violation reading from position 0x03696000.
This comes in 40 of 50 tries.
I have found out, that this behaviour has something to do with the Labview runtime. I've tried to link the Labview dll dynamical instaed of link it statically and I have seen that there is the same problem.But when I unload the Labview dll and wait until the Labview runtime is closed there comes now error. I also have tryied this 50 times.The Labview runtime needs 11 Seconds to close until the unload of the dll.
Are you sure you are passing any return buffer to those functions with its size big enough allocated in your C program? Passing in an array or string buffer that is to small will often cause the DLL to write over the end of that buffer destroying other memory locations that could be used by the runtime for its housekeeping. When you try to stop the application the DLL gets unloaded and its cleanup tries to deallocate anything previously allocated stumbling over corrupted memory areas that were supposed to contain pointers but now are simply trash.
Rolf Kalbermatter
StefanE wrote:I have checked this first and the buffers have the correct size.
All I can say is that although I usually end up doing the opposite, namely calling DLLs in LabVIEW, I have many times sworn that all buffers were perfectly sized only to find out that I was missing something somewhere such as an extrabyte for the terminating 0 char or passing in the number of elements to the DLL while taking that number as number of bytes and other similar things.
I can't authoratively say that you haven''t run into a bug/problem with the LabVIEW runtime itself but in my humble experience dealing with DLLs in LabVIEW, a crash was always caused by my or the DLLs programmers (often myself too) stupidity rather than a bug in LabVIEW.
Rolf Kalbermatter
StefanE wrote:
I think the problem is, that the C program ends before the runtime has closed. So the error comes with static and dynamic linking of the dll. But not with dynamical linking if I unload the dll in my C program, wait manually (getchar) until the Labview runtime has closed and return then from the main function.
That might be a possibility. Although a DLL is always linked dynamically 
I did check about the LabVIEW DLL itself. For LabVIEW 8.5 DLLs at least its DLLMain() function seems to do something that is considered rather bad by Microsoft. When it is called with DLL_PROCESS_DEATTACH it does always do a FreeLibrary() for lvrt.dll independant of the value of the third parameter "lpvReserved" to DLLMain(). This parameter is not very well documented on MSDN but there do exist some MSDN articles that warn explicitedly to do anything involved, and especially call FreeLibrary() for the DLL_PROCESS_DETACH case if this third parameter is not NULL. In that case the process that loaded the DLL is itself terminating and a lot of Windows APIs especially dealing with resource management are anything but safe to call at that time.
Also trying to unload DLLs and deallocate Windows resources in process termination is although a noble idea not really necessary since Windows will do that on behalve of the process, (and probably has done so already for some resources before some deallocation routine executes that got triggered by the FreeLibrary() call).
I would think this to be a clear case for a CAR.
Rolf Kalbermatter
StefanE wrote:Hi,
thanks for the regards. I've tried to create a smaller dll but with that I get no error. I was also not able to reduce the error to a function or attribute.
With my dll I do three things:
- call the LVDLLStatus function
- call my function
- return from main program
That's enough to get the error. To get a feeling my dll contains more than 1000 vi's.
Perhaps it can have something to do with this error message?:
one exception (First-chance) at 0x7c812a5b in CallLVDll.exe: Microsoft C++-exception ni::dsc::exception::InvalidArgument at memory position 0x0186df44..
I get this error message every time I call a Labview dll. I have added an example project for this. I ignored that message, because it happens with the first call to a function of the labview dll, it doesn't matter what for a dll or function. So I think it's something internal in Labview.
Best regards,
Stefan
Your first error sounds more like a problem with your LabVIEW installation. Did you ever install the LabVIEW DSC Toolkit? You may not since part of the DSC technology is also used for things like the Shared Variable engine, but there could be some corruption somewhere.
Where did you happen to come across the LVDLLStatus() function? I'm not sure it is valid to pass a NULL pointer for the module variable.
Also is your other application multithreaded? You may have a problem with this here http://detritus.blogs.com/lycangeek/2005/05/labview_and_asp.html
Rolf Kalbermatter
