09-11-2013 02:45 AM
Hello
I am using a dll in LabVIEW that crashes LabVIEW after a view call cycles.Unfortunately I have no way to get the supplier to change anythin in the dll.
From my view it seems the problem is in the dll. I narrowed down the problem to opening and closing a session to a device and calling init and close.
I call these function sequence in a loop in LabVIEW, which after a random number of calls leeds to a crash of LabVIEW:
err initDriver()
err openSession(ref*)
err closeSession(ref)
err closeDriver()
So I think there is not so much to mess up here and I am pretty sure the fault must be in the dll.
My question now is: Can I do anything to prefent LabVIEW from crashing?
Would it help any if I put all calls in a wrapper dll? Would it help to use implicit binding of the dll with LoadLibrary with initDriver() and UnloadLibrary with closeDriver() in the wrapper dll?
Thanks for advises
09-11-2013 04:33 AM
Hello DAckermann,
Could you provide more information on the crash? Do you see an error when this happens? Does LabVIEW close completely, or just the VI you are running?
There are a few possibilities as to why this DLL would cause the calling application to crash, knowing more about any errors you are seeing (if there are any) might help pinpoint what is awry.
Also- have you tried maintaining the driver session rather than opening and closing it in a loop? Is this feasible in your application?
Regards,
09-11-2013 01:09 PM
Hello Tom L.
It is a crash where you get a dialog that LabVIEW had to be closed, because it generated an error. I can post a screenshot of the dialog tomorrow.
Normally in an application this session will be opened and closed only once. So this should work. But during development it is a real pain. Because you start and stop your vis..
Thanks
Regards
Dermot
09-12-2013 05:24 AM
Here some more information about the crash
lvlog.txt:
####
#Date: Do, 12. Sep 2013 12:16:27
#OSName: Windows 7 Professional Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: LabVIEW
#Version: 11.0.1f2 32-bit
#AppKind: FDS
#AppModDate: 07/13/2012 17:36 GMT
#LabVIEW Base Address: 0x00400000
Possible path leak, unable to purge elements of base #0
12.09.2013 12:18:25.789
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: b611106b-f390-48b9-9634-41f4926b32c6
ExceptionCode: 0xC0000005
¥lqq€¡í
0x01AB6B29 - LabVIEW <unknown> + 0
0x01AB7068 - LabVIEW <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x771E003F - kernel32 <unknown> + 0
0x77DA74DF - ntdll <unknown> + 0
0x77D69EC5 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
09-12-2013 10:35 AM
Hello Dermot,
It appears the error you are seeing is a generic memory access violation- something (in this case it's pretty clear that it's the DLL you're calling) is overwriting memory already reserved for use by LabVIEW. There is realistically not much we can do about that in this situation unless you have access to the DLL source, but I would get in touch with whomever provided you with the DLL and see if they are aware of the problem and determine if there are any caveats to calling the DLL - there may be some sort of built-in debugging or status tool that could be queried to determine the state of the library before reinitializing.
Regards,
09-12-2013 11:05 AM
There is no technical support for the dll and no sources available..
But would it help to create a wrapper dll that uses LoadLibrary() and UnloadLibrary()?
09-13-2013 05:24 AM
@DAckermann wrote:
There is no technical support for the dll and no sources available..
But would it help to create a wrapper dll that uses LoadLibrary() and UnloadLibrary()?
Creating a wrapper (with for example the fonctions in the loop packed in a single call library function node) could be tested (especially that this operation/test does not requires a big ammount of developing time.
Regarding the Load and Unload Library... Could you be more specific? Was your idea to load the DLL the dynamical way at the start of the program to make sure the function entry point is correct or to load/unload it at each loop iteration?
Also did you checked a potential memory growth while the program runs? Could it be possible a malloc() memory reservation is not deallocated?
Last question: Is there for your instrument only a C DLL available or could there be other libraries (such as a .NET Assembly) available?
Best regards
09-13-2013 05:56 AM
Hi,
I had a similar problem, but with other dll. The problem was resolved by installing the newer version of LabVIEW.
Simyfren
09-17-2013 01:36 AM
Hello Florian
Sorry, I was not correct in my first posts. I meant explicit dll linking with LoadLibrary() and FreeLibrary().
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/ms683152%28v=vs.85%29.aspx
The idea was to have a wrapper dll for the driver dll. The driver dll should leave memory when I call the wrapper function closeDriver().
But this would require putting all the other driver dll functions in function pointers..
I think I will live with the crashes. In the resulting application (Exe) it seems to work fine.
Thanks again