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 <hex mem addr>
referenced memory at <hex mem addr>. 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 tried 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.

[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.