the same code, different exe files 2

[seoul]

I find another problem, my exe file has a button to stop the file running and exit Lv. But when I click it, there is a warning dialog said this application error. some memory cannot be read. I donot know why.

[didierj]

Could you at least post a pix of the error box?

[Steve Griff]

Question?

Does your Labview call any .dll?

I have a similar problem, closest as I can tell is Labview is trying to do an auto garbage handler on Exit and some how the reference to the .dll is all ready gone.

The fix I use is a command-line call to the OS to kill the App run, and clean up.

So far all is good.

[Rolf Kalbermatter]

Question?

Does your Labview call any .dll?

I have a similar problem, closest as I can tell is Labview is trying to do an auto garbage handler on Exit and some how the reference to the .dll is all ready gone.

The fix I use is a command-line call to the OS to kill the App run, and clean up.

So far all is good.

Most likely you do something wrong when calling your DLL. There is no way LabVIEW should be able to access memory controlled by your DLL outside of calls to your DLL. The most likely cause of these is actually that you pass a to small buffer to a DLL function that tries to write to that buffer. In C the caller (eg. you as LabVIEW programmer) has to allocate the buffer. LabVIEW can not even guess how big such a pointer should be so you have to tell it. You do that by creating the LabVIEW array or string with functions such as Initialize Array with the necessary size before passing it to the Call Library Node.

Most people think that an empty array constant as input is enough since that is how it would work in LabVIEW. But the C function can not dynamically resize the array to the size it would require so it just assumes that the caller has done that already. LabVIEW however can not resize it automatically before passing it to the C function since it has no idea if that array should be 10 bytes or maybe 100 MB. Passing an empty array will basically cause LabVIEW to pass a pointer to a zero length buffer. Now your C function writes into that zero size buffer and overwrites data it should not even look at. If you are lucky you get an Illegal Access Exception when that memory has not yet been allocated to the process at all. More likely however the memory area follwing that pointer is already used by LabVIEW for other purposes including its own diagrams, front panels, management and what else. If you are still a bit lucky you destroy very important information that will soon cause LabVIEW to crash. In the unluckiest case you just overwrite memory that is actually part of your VI definition in memory. Then you do a save et voila you got a corrupted VI on disk that might not be possible to load into memory anymore!!!!!

In your case there gets data overwritten that seems not very important but renders some pointers invalid. At the end when LabVIEW tries to properly deallocate all that it has allocated before, it stumbles over these invalid pointers and crashes. Killing your app only avoids the symptome but doesn't cure the cause.

So if you get strange crashes check if you use DLLs anywhere. If you do and those DLLs came not with LabVIEW itself you should get very cautious. Stress test them as much as you can with the setup as is used in your application. You may be using a time bomb in your application!! It may seem harmless now but seemingly small changes to the app might cause the corruption to be moved into much more sensitive areas and there your app crashs consistently somewhere seemingly unrelated because you added this single button to that nice user interface and post here that LabVIEW crashed because of adding a simple standard button to your VI.

Rolf Kalbermatter