ni::dsc::exception::InvalidArgument

[jojp]

Hi,

I run Visual Studio 2005 with LabVIEW2009. I have a project with CLF and a DLL with pulls a LabVIEW event.

The VIs and DLL work. But when after running the stoping. LabVIEW freezes.

And even worse: Opening the VI and closing also leads to freezing LabVIEW. 

And even worse: With MSVS in Debug mode attached to LabVIEW, I get the following error when I open my project:

Eine Ausnahme (erste Chance) bei 0x7c812afb in LabVIEW.exe: Microsoft C++-Ausnahme: ni::dsc::exception::InvalidArgument an Speicherposition 0x0012af68..

(Yes its a german MSVS)

Once again: The VI & DLL do what I want the to do. But closing the VI freezes LabVIEW you have to crash it.

Thanks for your help.

[Duffy2007]

hi jojp,

i have found a thread in the forum in wwich a similar case is posted

C program crashes at the end with First-chance exception in InterfaceTest.exe: 0xC0000005: Access Vi...

also this

Can LabVIEW call a DLL built with VS(2005) C++ with /CLR and Without an Entry Point

Can you post the code that closes LabVIEW?

[jojp]

Hi Alex, thanks for your help. I will read this post carefully and answer then detailed.

[jojp]

The C++ DLL which I called with CLF was broken. I always crashed when closing. No problem form single run application.

But a big problem form me because it crased LabVIEW as well. 

[Brad_K]

Hi jojp,

It sounds like you found the problem with the DLL. Opening a VI containing a call library function node loads the corresponding DLL (unless the DLL name is passed in on the diagram, in which case the DLL can't be loaded until you run the VI). So opening and closing the VI does load and unload the DLL, which exercises its DllMain(). Was the DLL's DllMain() function doing something it shouldn't, such as calling LoadLibrary() or FreeLibrary(), or waiting for threads or synchronization objects? 

Seeing first-chance exceptions in the debugger doesn't always mean that there is a problem, so they may be unrelated to the hang. When a program raises an exception, the Visual Studio debugger gets two chances to handle it:

• The first chance occurs before any of the program's exception handlers (such as try/catch blocks) are executed.
• The second chance occurs if the program's exception handlers do not handle the exception. When Visual Studio displays a second chance exception, then there is definitely a problem, and the program would have crashed with an "unhandled exception" error if the debugger had not been attached.

Brad

[jojp]

Hi Brad,

thanks for your thougths on my case.

I crashed LabVIEW also by simple executing a LoadLibary() and  a  consecutive FreeLibrary() call. (CLF with kernell32.dll)

Unfortunatley I didn´t have the sources of the DLL if was wrapping with my LabVIEW DLL.

So it was not LabVIEWs fault.