I have a small VI which call two API from a DLL. When I press Register, the FI_Register_wrapper() is called and when I press 'Registering', FI_get_handle_by_name_wrapper() is called. Both the calls works perfectly. But when I close the VI the LabVIEW is crashing. It is giving Access violation at EIP error. Please help. I am including my VI also.

@skariaroy wrote:We checked the library to find anywhere the dll corrupts the memmory. We tried it numerous times using multiple tools and couldn't find any place where the dll corrupts the labview memmory. So the dll is perfect. It is not possible to write the entire dll stuff in LabVIEW. We have to code in C++ since we already have the dll.The fact that it crashes is enough proof that your assertion that your DLL is perfect is not true! It's as simple as that! @skariaroy wrote: CameraServices* cs = new CameraServices( name );return FI_OK; reffrering the code above which is a part of dll. if I return from the function before allocating a memmory of type CameraServices*, the program is not crashing. The statement CameraServices* cs = new CameraServices( name ). makes the application to crash. It is just a memmory allocation. Why does LabVIEW even care about it? LabVIIEW doesn't care about that memory allocation! It's memory that your DLL allocated and LabVIEW will be happy to leave that memory alone. What most likely happens though is that something in that call is not behaving properly and is corrupting memory that it has no business to even touch! It could be that the name parameter is something else than you think it should be, and which you therefore pass wrongly from LabVIEW to your DLL, or it could be as simple as a bug in the constructor for that class. Or some other misfortunate thing such as driver mismatches in the lower level components of your CameraServices class. One more observation: the code as you write it will leak the CameraService object every time you call that function. That won't cause LabVIEW to crash though (not quickly at least until it runs out of memory). What I can assure you with 120% certainity: It's not LabVIEW caring that you create an object of type CameraClass in your code but it is something in the code you wrote or in the code you call that misbehaves. And unfortunately your observation is not enough to pinpoint the cause definitely. Leaving away that call may seem to solve the problem but reality is that the bug may be somewhere completely elsewhere in your code, but by leaving away that call the memory layout is also rearranged and your bug will corrupt other memory not as vital for LabVIEW. It may still crash sooner or later. And it's not LabVIEW's fault that you don't have to care about these trouble when you program in LabVIEW. But you program in C(++) now and that comes with its own and a lot more nasty issues!

LabVIEW

Access Violation at EIP - Causing Crash

Solved!

Author

Hello,

Finally got it working. We had another dll running in a thread called websockets.dll. When the LabVIEW is closes, the dll is been released while thread is till running. We modified the dll to shutdown the thread when we run the Unregister(). which solved the problem.

Message 11 of 11

(1,148 Views)

LabVIEW

Access Violation at EIP - Causing Crash

Re: Access Violation at EIP - Causing Crash