DLL causes LabVIEW new/open dialog box to crash on exit

[DougF]

I have written a DLL in VC++ using MFC that has several exported functions. I am using LabVIEW 6i on a Win2000 machine. All functions in the DLL work as expected and return correct values. When I close my application VI, the LabVIEW New/Open VI dialog box displays as normal. When I try to close the dialog box or open another VI the dialog box crashes with error "The instruction at referenced memory at . The memory could not be read".

I do not have to run the application VI to have the problem, all I have to do is open and close it. If I remove all "Call Library Function" VI's that reference the DLL, the problem goes away (of course the application doesn't work either). I have t
ried changing the calling convention from C to stdcall and get the same problem.

Thanks in advance for any insights into why this is happening,
Doug Forsythe

[Ben]

Hi DougF,

It has been a while since I looked at this stuff in detail, so I will answer from memory.

There are a number of routines that must be present for the code to work correctly. The two I am thinking about are "CINDispose" and "CINUnload".

I suspect CINUnload is missing or buggy.

I hope this helps,

Ben

[DougF]

Hi Ben,

I appreciate your help. I will research CINDispose() and CINUnload().

Doug Forsythe

[Randy_H]

Doug,

LabVIEW loads the DLL when the VI is loaded. Does your VI do anything specific when it is loaded? Since it is getting loaded by LabVIEW, it is near LabVIEW's memory area. It could be doing something to LabVIEW's memory that always affects the dialog box. Also, we just use the standard Windows File dialog box, so there could be an issue there as well (MFC not getting intialized correctly in the DLL or something like that).
Obviously there is an interaction with the DLL, we just need to find it.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[DougF]

Hi Randy,

Yes, the DLL instantiates a class that wraps a Microsoft ActiveX control, mscomctl.ocx. I can control when that class is instantiated and I have tried creating it upon start up and creating it after a user event.

I have also built the DLL using dynamic linking to MFC an and static linking, the same error occurs in either case.

If I don't use the ActiveX control, I don't have to link to MFC, the ActiveX control needs a CWnd parent. I would have to redesign and rewrite the DLL but if that's the only to solve the problem...

Thanks for your help,
Doug Forsythe

[Randy_H]

Doug,

Also, MFC and LabVIEW use very different threading architectures. If you use MFC, you should start all of the MFC items in a thread that you create from the DLL so that MFC can use the standard apartment-threaded model. This may also solve the issue.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[DougF]

Randy,

Oh, yes, that explains it, some clean up process is being called in a thread that has terminated. The reason I used the ActiveX control is that it generates window events within the apartment model thread (I'm running it in the UI thread). Handling comm port events in a single thread was easier than polling the port in one thread and synchronizing resources with other threads. There is no easy fix for this but at least I now know not to use apartment model OLE objects in code that I will call from LabVIEW.

Thanks,
Doug Forsythe

[Mihai]

Doug,

Did you ever get to the bottom of your problem?

I do not use any home-made DLLs, all I did was upgrade LV from 6.0.2 to 6.1 and a host of other drivers (like NI-SCOPE, NI-FGEN and the kind) to the latest available versions, and all of a sudden I started seeing the same message as you did.

Any hint in the right direction would be much appreciated.