LabVIEW 6.02 hangs on second call to dll

[stop bugging me]

I have written a dll in c compiled with cygwin that connects to a device driver for a DSP PCI board on a Windows NT4 SP6 machine. If I start LabVIEW and load\ (I dont have to run it) a vi that uses the dll and then close the vi two times without terminating labview inbetween, lavbiew partially hangs. I can still edit vis but I can not execute them. I can not exit LabVIEW either but have to teminate it through the task manager. I used a system utility to examine which dlls are loaded and unloaded and concluded that the error occurs when my dll has been unloaded once. The dll works perfectly the first time I load it. I think the error is related to multi threading. Everything works fine if I restart labview instead of just clo
sing the vi.

Best regards,
//Anders

[Aaron Marks]

If you think that you might be dealing with a threading issue, you can try forcing the VI which calls the DLL to run in single thread mode by setting it to run in the user interface thread. Make sure your DLL is set to run in the UI thread as well. Look in the Using External Code with LabVIEW manual for more info about threading issues. Also, if you have the ability to create debuggable executables you might try using it to see what is happening. Specifically, you need to make sure nothing odd is happening at your Process Detach.

[stop bugging me]

I tried to run the vis as user interface threads. The only improvement I could find was that the vis now could be opened 3 times instead of 2 before LabVIEW locked up.

Additional information: sometimes a small window saying

Resetting (of Restarting) vi: "name of vi"

comes up when I close the vi calling the dll after LabVIEW has locked up.

I have also found a (sort of workaround for the problem): If I open a vi that calls the troublesome dll and just leave it open (thus forcing LabVIEW not to unload my dll); I can open and run any vi any number of times without fault. It is first when I unload the dll from memory keeping LabVIEW running that the lockup occurs.

Thank you for your help,
//Anders