LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview has encountered a problem and close by windows

Dear All,
Here I have one question to ask for you. it is that labview was closed automatically by windows and return a information After I run a program(This program was written in labview, it called a .dll to completed a certain process.).  Please see the attached for the returned information.
who can tell me why?Thanks a lot!

 Best regards,
jimmy
 
 
0 Kudos
Message 1 of 11
(3,800 Views)
This means that there is probably something wrong either in the DLL itself or in the way you call it.
If, for instance, the DLL expects an array with 30 elements and you only gave it an array of 20, then it will overwrite something else in memory, which it shouldn't have overwritten and at some point, when LV will look for whatever was in the memory space, it will encounter a problem (and in this case, crash).
Make sure all the data you're passing into the DLL is of the correct type and size. Also, obviously, make sure the code in the DLL itself doesn't have internal errors.

___________________
Try to take over the world!
0 Kudos
Message 2 of 11
(3,808 Views)
Dear tst,
Thank you for your information. But i cannot find the reason.
now I attached my operating procedure and program to you. would  you please help me check what problem happen in my program?
thanks a lot.
 
regards,
Jimmy
0 Kudos
Message 3 of 11
(3,775 Views)
attach my program
0 Kudos
Message 4 of 11
(3,768 Views)
I truly have no idea. The most likely thing I can think about is that either the first array is not 6 elements or that you're giving it more or less than 6. You're also giving U16 instead of U8, but that shouldn't be a problem. My best suggestion is that you talk to whoever wrote that VI and\or DLL.

___________________
Try to take over the world!
0 Kudos
Message 5 of 11
(3,758 Views)
Well, right off the bat, the DLL is expecting an array of U8 and you're passing an array of U16 so that's not wise. Change the array to U8 and see what happens. Also check the calling convention is the same as what the DLL expects.

You might want to start with this document:

http://digital.ni.com/public.nsf/allkb/3B994675B17C654A86256FDD00754DD2

and the LabVIEW built-in help on calling external code.

-Saverio

0 Kudos
Message 6 of 11
(3,754 Views)

@smercurio_fc wrote:
Well, right off the bat, the DLL is expecting an array of U8 and you're passing an array of U16 so that's not wise.
As I said, that shouldn't be the cause of the crash because the CLF node coerces the U16 values to U8s (the small gray dot).

___________________
Try to take over the world!
0 Kudos
Message 7 of 11
(3,751 Views)
Yes, I saw that statement, and I apologize for not making a reference to it. However, "shouldn't" is the operative word here. The best thing is to make the datatype match outside of the DLL call. It's quite possible the DLL is getting garbage values from the implicit coercion and it's not smart enough to check the values for "good values" before operating with them, and that's what's causing the crash. I've seen instances where this happens, hence my recommendation to change the datatype to U8.

Of course, an alternative test is to call the DLL from a C program in exactly the same way as is done in the LabVIEW code and see what happens.

-Saverio
0 Kudos
Message 8 of 11
(3,750 Views)


@smercurio_fc wrote:

It's quite possible the DLL is getting garbage values from the implicit coercion and it's not smart enough to check the values for "good values" before operating with them, and that's what's causing the crash. I've seen instances where this happens, hence my recommendation to change the datatype to U8.

Can you reproduce this? This definitely shouldn't be happening. A LabVIEW coercion should happen purely inside LV and not affect the DLL in any way.


Of course, an alternative test is to call the DLL from a C program in exactly the same way as is done in the LabVIEW code and see what happens.

That is an option, although it will not necessarily help because the problem doesn't occur when calling the DLL, but only when closing the VI. Due to this, another suggestion would be to call the VI as a subVI. It was obviously designed to be called as such and that might cause the problem to stop happening. This is obviously not a real solution, because if there is memory corruption, it's best to find it near the source than at some later time, but it might work.

___________________
Try to take over the world!
0 Kudos
Message 9 of 11
(3,746 Views)
I change data type from U16 to U8,but the problem still happened.
It is a bluetooth pair program. I find that when i exit dongle driver before i close the program, the problem disppear. But I don't know how to write the program to exit the driver. Do you know that? Please advice. Thanks!
 
Regards,
Jimmy
0 Kudos
Message 10 of 11
(3,728 Views)